Danke für die Information Gppes. Es ist gut zu wissen, dass ich wenigstens nicht der Einzige bin, der über solche Details nachdenkt.

Eigentlich wollte ich in die Arbeit des ursprünglichen Mappers möglichst wenig verändern aber wenn ich das Vordach neu zeichne, würde ich es gleich um das Vorgebäude mit den Shops herum zeichnen und damit auch die Gebäudefläche veringern. Die Fläche außen ist nämlich begehbar (keine Ahnung ob öffentlich), ist nur im Osten des Vorgebäudes nicht vorhanden und eigentlich kein Teil des geschlossenen Gebäudes. (Die Wände beginnen erst innerhalb der derzeitigen Flächenzeichnung.)

Weiters würde ich den Tag building:part nutzen, wie es bereits für die Bettenhäuser verwendet wird. Im Süden könnte das westliche Nebengebäude auch als getrennter building:part gezeichnet werden, da dort weniger Stockwerke vorhanden sind. Nicht notwendig aber vielleicht sinnvoll wäre es alle building:parts in einer building:hospital Relation zu verknüpfen (optional auch tag healthcare).

Bei building:parts sollen die Umrisse in einem eigenen geschlossenen Gebäude als Fallback gezeichnet werden. Meiner Meinung nach gehört auch das Vordach zum Umriss auch wenn ich auf der südlichen Seite eher Bäume als eine Wand erkenne (aus Bildern - was keine außreichende Einschätzung ermöglicht).

Der Steg und Rolltreppenhaus (Fälschlicherweise teil des Vordachs) ist hingegen meiner Meinung nach kein Teil des Gebäudes. Ein Wartungszugang verläuft zwar über das Vordach, aber ich vermute keine windgeschützte Verbindung zwischen den Gebäuden. Außerdem wird das Gebäude vermutlich durch die Wiener Linien verwaltet (bzw. Wiener Netze).

Wenn da jetzt nicht etwas komplett abwägiges dabei war, trau ich es mir zu, diese Änderungen selber durchzuführen. Gerne kann auch einer von euch meine Vorschläge einbauen, falls dies besser durch einen erfahrenen Mapper geschehen sollte.

Das eine Relation auch möglich ist, habe ich meines Erachtens nicht ausgeschlossen. Da ich dafür eigene Tags erfinden muss oder bereits vorhanden Tags kombinieren müsste erzeugt das unnötigen Aufwand. Deine Vorrausetzung des physischen Kontakts für gemeinsame Nodes ist mir neu und ich konnte dies durch keinen Wiki-Eintrag bestätigen. Beim einem Node handelt es sich laut Wiki jediglich um eine Geolocation. In diesem konkreten Fall verweißt diese zwar auf unterschiedlichen Höhen (Layer, der nicht verpflichtend dem Node zugehörig ist), aber die gleiche Location spielt für beide Features eine Rolle. Wie gesagt, glücklich bin ich über die Lösung nicht, aber ich bin offen für Verbesserungsvorschläge. Wenn ich von konkreten Problemen, die dadurch auftreten wüsste, wäre die Verknüpfung durch Nodes sowieso uninteressant für mich.

Das Gebäude über den U-Bahn-Schienen ist dabei auch in keinem Zusammenhang. Es erfüllt keinen Zweck für die U-Bahn-Schienen und umgekehrt. Das Dach erfüllt für die Fahrbahn sehr wohl einen Zweck und verändert auch den Zweck der Fahrbahn. Zusammenhänge, wie die Möglichkeit eines Fahrbahnwechsels werden verknüpft, um auf diese Zusammenhänge hinzuweisen. Vor allem bei Tankstellen treten diese nodelosen Schnittpunkte auf, die allerdings nicht wie bei Brücken einen Zweck erfüllen. Dächer bei aufgelösten Grenzkontrollen haben keine derartige Beziehung. Wie unterscheidet man also welcher Sachverhalt vorliegt? Da es sich dabei um ein unnötiges Detail handelt, ist es die Diskussion eigentlich nicht Wert und ich habe angenommen, dass ein Node als Schnittpunkt am wenigsten negative Auswirkungen hat.

Ja und Nein. Ich wurde bereits von jemand Anderem gebeten, das zu unterlassen und habe den Tag auch seither nicht mehr verwendet. Unter osm.wiki/Proposed_features/crossing%3Dmarked findest du den Wiki-Eintrag, welcher natürlich aufgrund seines Statuses nicht anzuwenden ist. Ich habe die Authentizität von iD-Warnungen zu meinem Bedauern nicht angezweifelt. Dienste auf gleicher Subdomain werde ich in Zukunft nur für openstreetmap.org nicht automatisch vertrauen.

Ich bin immer für bessere Vorschläge offen. Das die Straße unter dem Vordach verläuft erfüllt einen Zweck, daher sollten die beiden Elemente auch in irgendeiner Art und Weise miteinander verknüpft werden. Das meine Änderung nicht optimal ist ist mir klar, aber dann könnte man auch gleich sagen, dass Straßen bei Kreuzungen nicht miteinander verbunden werden müssen, weil es doch eh klar ist, dass diese einander kreuzen. Ich nehme an, dass du die Nodes bereits gelöscht hast.

Hi, thanks for the info. I just saw the attracted controversy. I will stop changing it. Sorry for my late answer.

Dem Grundsatz demokratisch abzustimmen habe ich doch bereits in einem früheren Kommentar zugestimmt. Die Wiki ist soweit ich es verstanden habe die offizielle Informationsquelle für Mapper und Entwickler, da sie auf der selben domain erreichbar ist. Bei deratig schwerwiegenden Vorwürfen sollte es möglich sein genug Anhänger zu finden, um ein Umdenken zu erzwingen.

Die Zusammenfassung von Tags ist vor allem für kleine Projekte mühsam. Man verliert den Überblick und vergisst Synonyme. Standartisierung soll nicht nur einfach den Entwicklern arbeit ersparen. Nicht umsonst ist es in OSM möglich einen zusätzlichen Tag zu setzten der näher auf den genauen Sachverhalt eingeht. Ziel soll es ja nicht sein, dass jede Straße aufgrund ihrer Einzigartigkeit nur einen eigenen Tag hat und man aus dem Tag über 3 Umwege herrausfinden kann welche Kathegorie die Straße am ehersten hat.

Danke für die ausführliche Antwort. Ich habe eine wesentlich unangenehmere und aggresivere Antwort erwartet. Selbstverständlich war das in vielerlei Hinsicht eine Übertreibung. Validatoren, die einfach nur Fehlermeldungen abarbeiten, ohne zumindest in Satellitenbilder zu überprüfen, ob die Darstellung der Realität entsprechen kann, sind definitiv verwerflich.

Die Kreativität und Genauigkeit von Mappern muss allerdings durch Warnungen sehr wohl eingeschränkt werden. Wenn zum Beispiel ein Mapper auf highway=minor besteht ist das vorerst kein Problem. Werden diese allerdings mit der Zeit nicht umgetaggt - was den menschenlesbaren Informationsbestand fast nie verbessert oder sogar verschlechtert - kennen Apps den Tag mit der Zeit durch Ausleseverfahren nicht mehr. Für Apps ist eine Karte nicht einfach Striche auf einem Blatt Papier, wie zum Beispiel Kunst. Spätestens die Apps müssen intern ähnliche Tags zusammenfassen, um Informationen vergleichen zu können. Die Dauer nach der interne Zusammenfassungsregeln abgebaut werden, sollte meiner Meinung nach kürzer sein. Siehe osm.wiki/Deprecated_features um zu erkennen wie viele deprecated Tags auch noch nach mehren Jahren immer noch verwendet werden.

Ich weiß nicht, ob es für private Datenbanken bereits Lösungen gibt, in denen eigene Änderungen auf Osm hochgeladen werden, aber Änderungen Anderer erst bestätigt werden müssen bevor diese auch in der eigenen Datenbank übernommen werden. Dabei muss der Nutzer vermutlich hin und wieder aktiv werden, wenn Änderungen auf abgelehnte Datensätze aufbauen, aber theoretisch sollte das Möglich sein und deiner Beschreibung entsprechen. Das habe ich mit meiner Anmerkung gemeint.

Das ich nicht der Erste war, der Furte umgetaggt hat ist mir aufgefallen. Die wenigen "highway=ford" wurden fast alle mehrmalig von dir zurück getaggt. Wenn in der Wiki geschrieben ist, dass eine Art zu mappen zum Beispiel abadoned ist, sollte man einem Mapper nicht übel nehmen, dass er diese als logische Reaktion ändert. Sollange dieser überprüft, ob die Tags noch immer einen zumindest ähnlichen Zustand beschreibt und Satellitenbildern zusätzlich die Existenz untermauern ist, sollte es möglich sein aus den gewonnen Daten zu profitieren.

Fakt ist, das sich die Realität und die Art diese zu mappen einem ständigen Wandel unterworfen ist. Um die Karte relevant zu halten muss es auch neuen Mappern möglich sein Daten hinzuzufügen und anzupassen. Es geht nicht um einen Revierkampf in dem das eigene Territorium aggressiv nach seinen eigenen Meinungen konserviert wird. Selbstverständlich - und da stimme ich dir zu - sollen Entscheidung demokratsich getroffen werden. Dabei kann eine Standartisierung nur selten einstimmig sein, da bestimmte Sachverhälte dadurch schlechter oder schwieriger dokumentiert werden. Auch Straßen unterscheiden sich grundlegen voneinander und trotzdem werden sie in einheitliche Kathegorien eingeteilt. Ältere Mitglieder ärgern sich bestimmt immer noch über die Nachteile der gewählten Kathegorien aber für später hinzukommende Mapper ist das selbstverständlich und Analysen/Routenplanung wäre undenkbar.

Natürlich ist es nicht gut wenn unerfahrene Mapper in der Karte Fehler einbauen, aber Fehler gehören zum Lernprozess dazu. Am Anfang ist es schwer alle notwendigen Informationen zu finden, zu verstehen und dann anzuwenden. Wenn es Missverständnisse gibt sollten Anfänger freundlicher auf Fehler aufmerksam gemacht werden und Informationen mehr als Feedback übermittelt werden. Teilweise finde ich die Kommunikation grenzwertig, wenn auf den Fehlern Anderer herumgehackt wird, selbst wenn diese sich dafür entschuldigt haben oder den Interessenskonflikt eingesehen haben. Es wirkt so als würden einige standardmäßig davon ausgehen, dass Andere ihre Daten zielgerichtet sabotieren wollen. Die konstruktive Zusammenarbeit mehrer Mapper ist der Vorteil eines Community Projekts wie Openstreetmap. Wer nicht will, das die eigenen Daten von anderen verändert werden können oder spezielle eigene Vorstellungen hat kann eine private Datenbank (die auf Openstreetmap basiert) verwenden.

Vielleicht habe ich nur zufällig keinen von den von dir angedeuteten umgemappten Furte erwischt, aber von mehr als 10 Furten haben alle davor nicht existiert oder waren bloß Teil einer Linie.

Eine Kompromisslösung ist nicht notwendig. Ich habe gedacht, dass beide Tags in Ordnung sind aber wenn dich das Entfernen von ford=yes glücklich macht entferne ich es gerne. Das bedeutet dann, dass der Furt auf der Standardkarte nicht mehr angezeigt wird und vermutlich zunehmend von Programmen nicht mehr als solcher erkannt wird, da der Tag, wie gesagt, abadoned ist.

Soll ich in den Changeset der anderen Furte kommentieren, dass auch highway=ford in Betracht gezogen werden sollte? Ich kann die Falschinformation in meinem Changeset über deinen Wunsch mit einem Kommentar auf mein eigenes Changeset richtig stellen. Ich wollte dabei nur, dass das Kommentar des Changesets genauer spezifizieren um auf deine Kritik zu reagieren.

freebeer I agree with your opinion that crossing between roads and tram lines that do not exist in reallity should not be marked as crossing. But as far as I can tell a lot of roads need to be splitted into two or even more individual oneways too make that possible. In my changesets I tried to avoid marking non existing crossings but I may missinterpret some of them or, caused by the inteface, added crossings on an also crossing street somewher else than I wanted to. I realised that very lately. I am very sorry for these hopefully rare cases. I am open for critic whenever it is about a specific problem.

On the other side there were cases where cars had to cross two tram lines but the road was ony crossing once. Then no warning ocurres because the osm rules only require to connect lines that cross each other on the same layer. I would like to admit that I mainly focus on trivial issues like an ambassy or public building that is an amnety, unify company names by wikidata brands and connecting buildings that cross buildings because a point is not connected.

Bezogen auf "Automated edits are strongly discouraged unless you really know what you are doing!" habe ich bei jeder Warnung abgewägt, ob die Änderungen der Realität entsprechen und erst dann die Änderung durchgeführt. Automatisiert wäre das ganze in wenigen Minuten gegangen.

Ich habe mittels Overpass Turbo in den Daten von vor vier Tagen nach weiteren "highway=ford" gesucht. Kein weiterer Furt ist von mir editiert worden. Gleichzeitig ist mir aufgefallen, das "ford=*" in den Gebieten Süd-Westlich von Wien flächendeckender und statt von einem Mapper von mehreren Mappern verwendet wird. Diese haben wohl den Status "abadoned" von "highway=ford" anders interpretiert.

Für den betroffenen Furt habe ich jetzt beide Tags gesetzt. Ist das so in Ordnung?

Ich beziehe mich dabei auf die OSM Wiki (osm.wiki/Tag:ford=yes), in der von highway=ford abgeraten wird. Wenn du darauf bestehst kann ich den einen Node rückgängig machen aber ich hoffe wir können uns darauf einigen, dass es keine reine Verschlechterung ist.

Ja, sobald ich einmal wieder dort bin verwende ich GPS. Das der Plan eher schematisch war ist mir klar, aber die Anzahl der Brücken wird hoffentlich passen. Die Anzahl der Querungen wirkt außerdem für mich unrealistisch. Immer wenn ich mir nicht sicher bin hinterlass ich ein fixme. Ich hätte auch über das gesammte Tal sämtliche Warnungen, die sich automatisch korrigieren lassen machen können. Ich will nur verhindern, dass das jemand macht der sich überhaupt nicht auskennt. Die vierte Methode mit dem versickern ist aber ebenfalls auf Layer -1 zu verschieben. Nur weil Wasser versickert bedeutet das nicht, dass das Wasser verschwunden ist. Es ist nur auf einer anderen Ebene.

Laut diesen Plan https://www.myrafaelle.at/wp-content/uploads/2017/08/mu_plan_1.jpg würde ich davon ausgehen, dass mindestens eine Querung gestrichen werden kann, da der Verlauf so aber schon seit längerem ist habe ich gedacht, dass ich am Besten nur Brücken einzeichne und den Rest so lasse.

Das fixme ist noch drauf weil der exakte Verlauf immer noch nicht passt. Ich kenne die Gegend auch mehr oder weniger genau. Eines ist hingegen sicher. Wenn sich ein Weg/eine Straße mit einem Fluss kreuzen müssen diese durch einen Ford verbunden werden oder sich auf verschiedenen Layern befinden (Brücke/Tunnel). Deswegen warnt auch der iD-Editor.

Ok, I understand. In future I will ignore this warning but be aware other mapers are able to automatically change busstops in big areas. For example a mapper with nearly no experience sees a lot of warnings, zooms out and change the tags all over Vienna with one click (excluding the upload progress). That is why it might be a good idea to check your bus stop shema on some station regulary. Then you undo the changeset itself instead of manually correcting every station (which would take forever).

However, in fact I am a native Viennese but normaly I avoid changing public transport realted items. That is why I have less experience with the local schema. Especially, because I ran into mappers that were kind of unfriendly. I tell you this because I think that you might interpret the locale attribute of my changeset as my native language/location. Using a foreign language for mapping is a good way to avoid problems explaining map related information.

Thank you for this reminder. When I first saw this error I checked the OpenStreetMap Wiki (osm.wiki/Tag:highway%3Dbus_stop). According to it "highway=bus_stop [...] is [...] widely used on a node positioned to the side of the road (where passengers wait).". Should it not be standardised to make analysing more easier?

I also checked that platforms are connected to other highways before adding the footway tag. According to the wiki it is not required to add this tag but it is suggested by the iD-Editor and it somehow makes sense that a plattform has to be accessable for pedestrians which is indecated by the tag.

You can answer in German if you prefer. Thanks

Hi Frans, good to see you again. I spotted a problem with stream (679075706) which was laste edited by you. It looks like the whole stream was moved to the east. In older versions the position of the stream is correct. Some roads are still connected to it. Every ford node of crossing streets is also moved to the east because it is shared with the river. This causes a lot of warnings and looks awkward in the map. The stream should be moved back to west before unexperienced mappers start to solve only parts of the caused warnings. Because the stream is too big I am not allowed to move it in the iD-Editor. Could you pleace move it back in JOSM or undo the movement?
Johannes

I apologize that the description of my changes is not complete and creates confusion. Refering to the OSM Map Feature Wiki "oneway=-1" is "for traffic direction opposite to the sequence of nodes of the way (if the way cannot be reversed)". My original goal was to reverse the node sequence and change oneway to yes for oneway=-1 features that I can reverse trouble-free. I did this as you can see in my Changesets. Then I saw some unmapped pedestrian crossings and got away from the goal in some of my changesets. I forgot to mention this features in the description.

I hope you understand that my changesets are not vandalism and remove your report (if possible). In general I would prefer to discuss about it before you report it.