@woodpeck

Es geht doch immer noch eine Stufe tiefer. Die Tatsache, dass man hier Kritiker aussperren lassen kann halte ich nicht für akzeptabel. Nochmal: Aus http://resultmaps.neis-one.org/osm-discussion-comments?uid=4945640&commented sollte zweifelsfrei ersichtlich werden, dass ich nicht auf den User flohoff, sondern auf dessen Aussagen, wie auch auf Aussagen anderer mit gleicher Intention reagiere. Es wird in solchen Changesetkommentaren versucht auf die Mapper dahingehen Einfluss zu nehmen, zukünftig so zu erfassen, dass eine Auswertung/Bearbeitung für die Erstkommentatoren am einfachsten möglich ist, auch wenn der eigentliche Ersteller des Changesets durch sein Handeln/Mappen schon deutlich gemacht hatte, dass er anderer Meinung ist. Versuche hier Dogmen zu etablieren sollte jeder grundsätzlich misstrauisch betrachten. Dieses Verhalten ist geeignet eine Diskusionspraxis fest zu installieren, welche im Vornherein Gruppen und deren Ansichten von der Debatte fernhält. Es scheint sogar als solle verhindert werden andere Auffassungen überhaupt zu zu reflektieren. Die Verkürzung sowie die Verdrängung des Sachverhalts und dieser Debatte könnte fatale Folgen haben. Sie führt dazu, dass die Beitragenden den Durchblick verlieren und allzu einfachen Lösungsmustern anhängen. Es herrscht hier eine gleichgeschaltete Kultur des Wegsehens, des Wegdenkens. Der, der anders denkt, wird an den Rand gedrängt, ausgegrenzt und indirekt aufgefordert sich nicht weiter damit zu befassen sondern es unreflektiert als "gottgegeben" hinzunehmen. Denkverbote halte ich grundsätzlich für nicht zielführend um mit OSM weiterzukommen. Der "Störenfried" ist der, der ein eingefahrenes Projekt wieder dazu bringen kann, sich weiterzuentwickeln. Andere Sicht- und Denkweisen müssen zugelassen bleiben. Ich kommentiere diese Äußerungen bewusst bereits in den Changesetkommentaren, da diese ja eine weitere Diskussion im Forum/auf der Mailingliste unterbinden sollen. Mein erster Kommentar stellt grundsätzlich immer dar, dass es sich bei beiden Stile um gleichberechtigte Arbeitstechniken handelt indem ich auf osm.wiki/Editing_Standards_and_Conventions#Areas_and_Ways_Sharing_Nodesverweise. Eigentlich wäre zu erwarten, dass die Diskussion hiermit beendet ist. Aber wie aus den oben verlinkten Changesetdiskussionen ersichtlich ist, wird durch die Erstkommentatoren versucht meine Meinung und auch die des Changesterstellers, der sich ja schon entschieden hatte, zumindest als exotisch, meist als falsch oder sogar als allgemein verpönt zu diffamieren. Sie widerprechen zunächst meiner Richtigstellung. Mein Link auf osm.wiki/Editing_Standards_and_Conventions#Areas_and_Ways_Sharing_Nodessollte dem Changesetersteller verdeutlicht haben, dass beide Stile akzeptiert sind und dass er dem Manipulationsversuch nicht nachgeben muss. Ich erwarte für Mitarbeiter der DWG ein Neutralitätsgebot und fordere Gleichbehandlung - Eine Sperre für flohoff. Er hatte sich in osm.org/changeset/26043532 in meine Diskussion eingemischt.

[...] das von OF0 angeführte Dokument unterstützt hier doch klar flohoffs Aktion: "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."[...]

Dieser Teil des Wikiartikels belegt nur, dass dessen Verfasser wohl der selben Meinung wie du bist.

Sonst absolut nichts.

Hallo Ratz41,

auch hier war eigentlich alles richtig. Das 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

Hallo Ratz41,

Du hattest eigentlich nichts falsch gemacht. osm.wiki/DE:Tag:landuse%3Dgrass hat den Status in use.

Was wolltest Du hier erreichen?

Hallo,

was wolltest Du hier erreichen?

Was soll das denn sein? Willst Du Deinen Privatgrund kennzeichen?

place=plot hätte den Status in use
osm.wiki/Tag:place%3Dplot

@Protoxenus

Du gehst von der falschen Annahme aus, für jedes Objekt in OSM müsse ein Polygon hinterlegt werden. Es ist unlogisch einen nicht existierenden Raum zwischen Way und Fläche zu lassen. Außer man will dieses "Nichts" dazu missbrauchen Straßenflächen zu rendern. Das Rendern der Straßenflächen kann aber aus den Informationen im Way abgeleitet werden.

@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)