@Protoxenus

Ach so, Dein Problem ist also nicht der Mappingstil, Dein Problem sind die Unzulänglichkeiten der Editoren damit angemessen umzugehen. Weshalb verwendest Du Deine Energie nicht dazu auf deren Programmierer einzuwirken, anstatt Deiner Mitmapper Changesets vollzuschreiben? Wie wäre zum Beispiel ein optionaler Verkehrsinfrastrukturmodus, in dem alle Landuses ausgeblendet werden, sodass das man die Wege direkt bearbeiten kann. Wird ein Weg aufgetrennt, könnte automatisiert das angrenzende Flächenobjekt verbunden werden. Noch eine Möglichkeit wäre, dass, solange eine bestimmte Taste gedrückt wird, alle Nodes im Editor so behandelt werden als seien sie nicht verbunden. Es gibt etliche Möglichkeiten die Editoren benutzerfreundlicher zu machen. Die Hersteller der Editoren haben schon einen gewissen Einfluss auf das Mappingverhalten in der Community und können ihre Vorstellungen sehr leicht durchsetzten.

@Protoxenus

[...] Dort steht auch: 
There is not clear consensus yet on how to draw areas adjacent to ways. [...]

Ganz genau, das steht da. map55 hatte sich, mutmaßlich aus guten Gründen, dazu entschieden die Landuseflächen mit den Straßen zu verbinden.

[...] Aber wenn man es anderen schwer machen möchte, zählen ja keine Argumente [...]

Es geht nicht darum es anderen schwer zu machen, sondern darum die Realität mit vertretbaren aufwand hinreichend genau zu beschreiben. Es befindet sich kein "Nichts" zwischen den Wegen und Landflächen. Mit dem von Dir verwendeten Editor JOSM lassen sich über die mittlere Maustaste einzelne aus einer Gruppe übereinanderliegender Wege selektieren. Deshalb schrieb ich auch "vorgeschobene einfachere Wartbarkeit".

@flohoff

[...] Einfache Wartbarkeit ist DAS Argument bei einem gemeinschaftlichen Projekt. [...]

Zu zitierst mich nicht korrekt. Ich schrieb VORGESCHOBENE einfachere Wartbarkeit.

[...] Und ich und viele andere bei OSM haben dir über Monate hinweg mittlerweile gesagt das dieses verkleben nervig und unwartbar ist, und das du es bitte aufhören sollst. Das ist auch nicht fortschrittlich, im Gegenteil - Das ist ein sich bei OSM lange haltende unart. Wie auch das Wiki deutlich sagt - Die Lagegenauigkeit steigt wenn man es lässt [...]

Nein tut es nicht. Nur die Flächengrößentreuengenauigkeit der angrenzenden Landuses steigt. Dafür geht z. b. die wichtige Information verloren, ob sich noch etwas zwischen Weg und Fläche befindet. Auch das hatten wir schon. Auch der Weg ist eine Fläche deren Breite durch das width-Tag des Ways, hilfsweise mit Standardbreiten für den Wegetyp, anzugeben ist, welcher des verbundene Landuse verdrängt. Eine zweidimensionale Karte einer Kugel, welche auch noch Höhenunterschiede aufweist, ist immer ein Kompromiss zwischen Flächen- Winkel- und Streckentreue. Je nach nach Anwendungszweck wird der Anwender die für ihn geignetste Projektion wählen um zu rendern. Wir malen keine Karten sondern berstelen eine Datenbasis aus der der Anwender Karten erstellt. Es sind keine Scheinpolygone (Rendern durch weglassen) notwendig um Straßen darzustellen.

[...] (Diesen Teil unterschlägst du ja leider immer in deinen Zitaten) [...]

Ich verlinke in der Regel auf den Artikel und zitiere ihn nicht. Von Unterschlagen kann also nicht die Rede sein. Kannst Du msl schnell auf zwei drei Beispiele verlinken?

Das fortschrittliche Teilen von Nodes durch Flächen, wie etwa Straßen und angrenzende Landnutzungsflächen ist eine anerkannte Mappingmethode.

osm.wiki/Editing_Standards_and_Conventions#Areas_and_Ways_Sharing_Nodes

Vorgeschobene einfachere Wartbarkeit ist kein Argument.

Mach ich in der Regel und ist mir in diesem Fall durch die Lappen gegangen.

Mir scheint auch, die Wikidata-IDs der namensgebenden Teilorte verweisen manchmal (fälschlich?) auf Wikipediaartikel, welche die Gesamtgemeinde beschreiben. Ist schon noch ein bischen inkonstistent. Ich habe mir vorgenommen in solchen Fällen erst mal nichts zu erfassen. Die später wieder zu finden und anzupassen scheint mir recht aufwändig.

Nur mal ein Schnellschuß: Beispiel Neuenstadt am Kocher (Q32180501) beschreibt die Ortschaft, Neuenstadt am Kocher (Q503145) die Gemeinde. Sollte man die (Q32180501) am Knoten der Kernstadt und die Q503145 an die administrative Grenze, welche die Ortsteile umschließt, anbringen?

Aber selbstverständich respektiere ich andere Meinungen. Ich habe Deinen Changeset doch gar nicht revertiert.
Ich möchte Dich bitten zukünftig, insbesondere gegenüber neuen Beitragenden, nicht zu unterschlagen, dass es auch Berechtigte andere Meinungen gibt. Sonst setzt sich noch durch derartig angewandte schleichende Manipulation die falsche Methode durch. Sanjezz wird durchaus selbst in der Lage sein zu beurteilen, welche der gängigen Methoden die geeignetste ist. Solche Bevormundungen erregen doch immer den Anschein, als sei die von Dir bevorzugte Methode die einzig mögliche.

 Grüße zurück

Die Diskussion scheint hier weiter zu gehen:

osm.org/changeset/61960560#map=18/50.15319/9.14636

https://forum.openstreetmap.org/viewtopic.php?pid=624985#p624985 ??? Du meinst sicherlich:
https://forum.openstreetmap.org/viewtopic.php?id=31807&p=1
Auch in diesem Thread konnte kein Konsen erlangt werden. Weshalb führst Du ihn dann hier an? Wenn Du auf bestimmte Posts in diesem Thread Bezug nehmen willst, nenn' bitte hier deren Nummer.

[...]Außerdem sollte man auch den zweiten Teil von deinem beachten:

That being said, when the way is a highway, it usually is most accurate to include a gap, so that the area ends by the side of the road and does not share nodes with the road's way. This is because highway ways usually are traced along the centerline of the road, and it is unlikely that the area being tagged actually extends to the center of the road. [...]

Dies outed den Verfasser nur als Anhänger Deiner Meinung. Dass die Fläche des Landuses genauer in die Datenbank eingetragen wird, ist unbestritten. Er verschweigt aber, dass jetzt nicht mehr ermittelt werden kann, ob sich zwischen Straße und Landuse noch ein Objekt befindet. Es gehen somit wichtige Informationen verloren. Auch blendet er vollständig aus, dass Wege zwar mit einet Linie in OSM eingezeichnet wird, diese Linie stellt jedoch ein zweidimensionales Objekt dar, dessen Breite durch das width-Tag angegeben werden sollte. Hilfsweise kann mit Standadardwerten für den jeweiligen Straßentyp gerechnet werden um die Fläche der Straße zu ermitteln und dadurch die Fläche des Landuses zi verkleinern. Es ist die Aufgabe des Renderers dies entsprechend auf die Tiles zu bringen und nicht die das Mappers. Genau so verhält es sich beim Berechnen von Flächen. Das Herausrechnen der Straßenfläche ist die Aufgabe der Algoritmen und nicht des Mappers.

Gruß  zurück

Du solltest Deinen Changeset revertieren. Siehe osm.org/changeset/61957038

Das fortschrittliche Verbinden von Flächen mit vorhanden Straßen ist eine anerkannte Mappingmethode
osm.wiki/Editing_Standards_and_Conventions#Areas_and_Ways_Sharing_Nodes

Selbstverständlich geht der Park nicht bis zur Straßenmitte. Wenn Du das width-Attribut befüllst hast Du ein zweidimensionales Objekt beschrieben, welches den Park verdrängt. Falls das width-Attribut nicht befüllt ist, kannst Du mit Standardwerten für den Straßentyp rechnen.

[...] Selbst die (auf den von dir genannten Fotos abgebildete) Infotafel an den Mauerresten ist nicht mehr da. [...]
Heute stand sie wieder und sah nicht so aus, als sei sie in den letzten Tagen erneuert worden.
http://up.picr.de/33595758bb.jpg
http://up.picr.de/33595759is.jpg
Niemand lässt sich gerne verarschen...

Der Informationsverlust, der aus Deinem Entfernen von historic=castle resultiert, habe ich durch das Ergänzen von historic:historic=castle und historic:castle_type=castrum ausgeglichen. So können wir beide zufrieden sein. Es wird wieder gerendert, was Dir entgegen kommt und kann über die die Datenbank gesucht werden, was mir entgegen kommt. (siehe auch Diskussion in osm.org/changeset/61645288)

[...] Internetangaben können falsch sein, daher ist es am besten vor Ort nachzuschauen. Warst du vor Ort? [...]
Selbstverständlich können Internetangaben falsch sein, der Schein vor Ort kann aber auch trügen. Ich war vor wenigen Wochen vor Ort.

[...]Ich war heute früh nochmal dort. [...]
Schön für Dich.

[...] Keine Bodenformen, [...]
Musst du übersehen haben.

[...] keine römischen Fundamente zu sehen. Die Mittelalterlichen Mauerreste sind da, aber die gehören nicht zum Kastell. [...]
Aber deren Fundamente

Du schriebst:
[...] Auf der von dir genannten Seite gibt es auch den Abschnitt "Avoid MV tagging if..." [...]
Ich kann nicht erkennen, dass einer der gelisteten Punkte anzuwenden wäre.

[...] Aber davon abgesehen bist du leider nicht auf den Kern der Frage eingegangen. [...]
Was ist nach Deiner Meinung der Kern der Frage? Das Kastell ist tatsächlich vorhanden und zum Teil sichtbar. Siehe http://www.museen-mainlimes.de/content/3-fundorte/fundstelle.php?id=2

[...] Ich war gerade nochmal vor Ort: Es gibt keinen einzigen Stein oder sonst irgendwas vom Kastell zu sehen, auch keine Nachbildung, nur die Infotafel. [...]
Bodenformen, mittelalterliche Mauern mit römischen Fundamenten, ... Klicke auf die Bilder http://www.museen-mainlimes.de/content/3-fundorte/fundstelle.php?id=2

[...] Ich werde das daher entsprechend korrigieren so dass es der Realität vor Ort entspricht. [...]
Das tut es doch bereits. Niemand sollte fehlerhaft mappen, nur damit "Qualitätssicherungstools" keine Fehler mehr anzeigen. Was bezweckst Du damit? Möchtest Du "Deinen" Bereich frei von Fehlermeldungen in Qualitätssicherungstools halten? Vielleicht sollte man mal ein Qualitätssicherungstool gegen die OSM-Qualitätssicherungstools laufen lassen. Oder stört Dich mehr dass der Standardrenderer damit nicht zurecht kommt? Mappen für den Renderer bringt nur kurzfristige Befriedigung.

Die verwendeten Mehrfachwerte sind wikikonform erfasst.
osm.wiki/Multiple_values

Dass verschiedene Qualitätssicherungstools und Renderer damit nicht umgehen können und es ungerechtfertigt als Fehler oder garnicht interpretieren ist ärgerlich.
Dies ist aber in erster Linie deren Schuld und wir sollten uns nicht dazu verführen lassen für die Renderer oder Qualitätssicherungstools zu taggen. Die beste Vorgehensweise wäre Kontakt zu den Maintainern mit der Bitte um Abhilfe aufnehmen.

Dass das Kastell nicht mehr im besten Zustand ist, lässt sich aus ruins=yes schließen. Es handelt sich um ein Kastell, also ist castle passend. Als Typ ist castrum angegeben, passt auch. Reste sind auch noch zu sehen: Die On-the-Ground-Regel ist auch erfüllt. Siehe auch osm.wiki/DE:Tag:historic%3Dcastle und osm.wiki/DE:Tag:castle_type%3Dcastrum

Was genau stört Dich?

Die Daten des Geschäfts sollten in einen neuen Node mit dem Tag shop=fabric "ausgelagert" werden.

osm.wiki/DE:Tag:shop%3Dfabric

Mutmaßlich wäre office=it genauer beschreibend als office=company

osm.wiki/Tag%3Aoffice%3Dit

Hier befindet sich kein Park und selbst die von Dir erwähnte Grünanlage ist mehr ein Grünstreifen.