Hi,
thank you, that was not what I wanted to do, I corrected it in Changeset 108985753. I tried to outsmart iD and it backfired. I drew two buildings together and didn't want to draw both again therefore I deleted building=yes so that I can split the way and then close both before I retag them as buildings. Unfortunately when you use the wrong order of those steps iD wants to assist you by creating a relation but doesn't indicate it clear enough. Therefore I should use the JOSM tool that can split buildings along a line.

It is always good to know that someone notices my mistakes. It sometimes feels like no one notices/appreciates my changes even though I add hundreds of buildings in some of my changesets. Feel free to tell me if you notice a third relation like that. I can't rule it out that I made the mistake more than twice from what I remember.

Hi ravali_78,
can you please mention which imagery you used to confirm that those roads do not exist? In both Maxar and Mapbox, the source values of your changeset, the way 965155631 is indeed visible even though I agree that it can be argued that it should not be unclassified but agricultural whereas way 747747160 right next to it is not visible and I assume that you did not delete it intentionally.

At first I thought that I created those unclassified highways by splitting but it wasn't even some highway=road that I encountered around that time. I have no problem that you deleted those highways but it would have been easier for me to understand which roads you deleted if you would have waited with deleting those roads until I answered on your comment. Not everyone has the skills to take a look at deleted objects and it could cause confusion for unexperienced mappers instead of helping them to understand their mistakes. I did it with overpass [date:"2021-07-18T19:20:00Z"];way(id:965155631,965155630,965155628);out geom;.

In a community it is beneficial to don't immediately review a changeset as bad because of 3 out of 126 ways don't exist on your imagery. You should not blame users that use a different/outdated imagery as long as they don't delete/destroy the work of other users that are more recent on a large scale. A more detailed map (creating roads/buidlings) can outweight some less recent updates to existing roads. And even if you think that I made those mistakes on purpose it would be nice to give me a chance to explain myself.

Thank you for taking a look at my changesets. I appreciate to have a second perspective on my changeset and I can't find all of my mistakes.

Hola, I am thankful for this valid feedback. I am pretty sure that this isn't my only changeset I mapped like that. Furthermore, I can't remember all changesets that far in the past, therefore I would need to go back quite a while in my changeset history. In case you would like that I correct my changes I won't be able to start right now I hope it is not time-sensitive.

I would love to map individual houses however those need more precission and are more time consuming. My thought process was that residential areas without buildings in it are pretty much equivalent to "here is data missing". Furthermore, typically those houses are surrounded by treeless areas with varing purposes. I can't really tell the exact purpose and there might me overlapping areas for each purpose but all are related to living (in a residence) and it is easy to map a line that surrounds those areas combined. As there a multiple cultural differences in purposes I think residential is a good fit and it is a common hotosm strategy for multiple houses. However I understand that this doesn't fit all cultures and if the community has agreed on a good compromise or is open for the discussion I am here for it but I am not familiar with how to get in touch with the community.

La diversidad de idiomas y culturas es hermosa pero difícil de estructurar.

The iD-Editor is probably prefered because it can be instantly used inside the browser without installing additional software. I am a fan of this and see no reason why the issue checking differs from josm.

Some brands include very specific tags but I have to admit that I did not find them inside the wikidata database, so I did not know how to add tags. Such a change could be automaticly applied to all refering osm nodes/areas and shops that will be added in the future will get this tags too.

You are right, the Panda shop is not part of the Panda Express brand. I do not know how this mistake could happen. Maybe I clicked on the wrong button.

I would be very thankful if you could revert my changeset. I currently have no access to a computer with JOSM and I am unfamiliar with the progress. I will redo the changes that do not cause problems when I have more time.

Hi, I want you to know that I regret this and other changesets. I am sorry that I cannot fix this immediately. As soon as I have enough time I will go through my changesets and fix the changes.

I nearly did not start my first changeset because I do not want to use wrong tags. But the iD-Editor information was very clear that the tag is obsolete but fits into a standardized tag and I trusted the information because of same domain authority. In my opinion standardization is fundamental for meaningful maps. While going through the warnings I checked if the new tag somehow fits with the meaning of the old tag. (A deviation is often necessary for standardization) Futhermore, I checked if satellite images can confirm a building where e.g. a shop can be and try to spot obvious mistakes. So, I hope my changesets are not useless but probably changeset revertion is the best correction.

Concerning Panda Express, company names/franchises are protected. Especially in shopping streets the shop is one of many brands. If I can see many non-branded local shops are in the area and I am not certain I check the offical homepage and leave a fixme instead of updateing the tags when I am not sure. The tag fast_food=cafeteria should be probably added to the brand standard tags instead of appling it to each node/area itself. So future nodes that will be added to this brand get the changes too.

Thank you for the information about entrances, I thought they are supposed to specify the type of entrance more easier.

I can revert the changes to the embassies but I knew that office=embassy should not be applied to e.g. the ambassadors home.

Vielen Dank für die Korrektur

Der Relationentyp building:hospital wird weltweit bereits 4 474 Mal verwendet, also existiert dieser anscheinend. Der Tag building wird in Relationen allgemein oft verwendet.

Ich war auch verdutzt als ich gelesen habe, dass die optionale (daher nicht nötige) Relation zusätzlich zur Umrissfläche erzeugt wird und die Umrissfläche sogar ein Teil der Relation ist. Vielleicht weicht die deutschsprachige Wiki auch davon ab.

Das ich den Tag building=hospital bei Tiefgaragen verwendet habe wäre mir neu und müsste wenn überhaupt länger her sein. Vielleicht aus einer Zeit in der ich mehr auf die Tags des iD-Editors vertraut habe.

Der Tag building:part=bridge könnte alternativ für das Vordach verwendet werden. Damit ist der Layer dann so wie es auch die Gehfläche verlangt. Im Prinzip ist das Vordach eigentlich eine Brücke und da sie Teil des Gebäudes ist, ist man_made nicht zutreffend.

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.