User talk:Markus B

From OpenStreetMap Wiki
Jump to: navigation, search

Video Tutorials

Hallo Markus, du kannst die Datei mit VLC media player abspielen. VLC Media Playerlayer ist ein kostenloses Opensourceprogramm und kann hier für verschiedene Betriebssysteme heruntergeladen werden. VLC ist ein wahres Schweizer Taschenmesser und unterstützt eine Vielzahl von Dateiformaten. Longbow4u 20:04, 28 July 2008 (UTC)

Links auf der NFE-Stammtisch-Seite

Hallo Markus, Erstmal danke für deine nützlichen Links auf der Seite NFE-Treffen.
Richtiger aufgehoben sind sie aber auf einer ortsbezogenen Seite und nicht auf der Stammtisch-Seite. Mein Vorschlag wär daher, eine Landkreis-Seite Nürnberger Land anzulegen (diese fehlt leider noch). Als Vorlage kannst du die Seite Nürnberg verwenden. Besser wäre es wahrscheinlich sogar, die Seite Landkreis München als Vorlage zu nehmen, die ist auf dem aktuellsten technischen Stand. Wie denkst du drüber?

Hi, ich wusste nicht wohin damit und habe es enfach mal auf NFE "abgelegt" in der Hoffnung, dass Ihr damit etwas anfangen könnt. Verschiebe es wohin auch immer Du es passend findest (und schick mir den Link). Ich finde, wir sollten alles in der Metropolregion Nürnberg zusammenfassen (bei den paar Männiken die sich bisher für OSM engagieren). Wenn es denn mal Hunderte sind, kann man sich immer noch in Gruppen teilen. Die Information in OSM ist schon zerflettert genug, synergetische Konzentration ist m.E. hilfreich. Deshalb finde ich auch gut, dass sich die Gruppe NFE nennt. Und nein, ich will/brauche keine Landkreisseite. Gruss, --Markus 17:59, 7 August 2008 (UTC)

Fläche oder Punkt

Hallo Markus, Fragen zu deiner Ergänzung auf De:Howto Map A:
1. Woher kommt die Grenze 100 m² – habe ich noch nie vorher gehört?
2. Ich persönlich würde alles als Fläche eintragen, wenn ich die Daten habe – aus welchem Grund denn nicht? Unterhalb von 1 m² (Telefonzelle oder so) mag es übertrieben sein, aber ein Gebäude mit 10 m Kantenlänge …?
--Tordanik 17:08, 19 August 2008 (UTC)

Hallo Tordanik, die "Grenze" ist eine ganz willkürliche Erfindung meinerseits (deshalb explizit "ca."). Es gibt Objekte, deren "Punktförmigkeit" zwingend ist (Leuchtfeuer), und andere bei denen sie sinnvoll ist (Briefkasten). Häuser mit 10m Kantenlänge finde ich sinnvoll als Fläche zu beschreiben, die Gartenhütte mit 5m Kantenlänge nur noch bedingt. Muss ja auch noch irgendwie georeferenzierbar bleiben. Gruss, --Markus 17:27, 19 August 2008 (UTC)
Nun denn, dann habe ich den willkürlichen Zahlenwert mal entfernt, da besteht ja schon zwischen uns keine Einigkeit. Ich glaube auch ehrlich nicht, dass es jemandem beim Mappen hilft (schreibs wieder rein, wenn du anderer Meinung bist …). Die erste Fettschrift hab ich dann auch mal rausgenommen, es gibt wirklich schlimmeres als einen als Punkt eingetragenen Spielplatz. --Tordanik 19:43, 19 August 2008 (UTC)
Schade. Ich finde Richtwerte immer hilfreicher als keine. Gruss, --Markus 20:24, 19 August 2008 (UTC)
Ok, geht das als Kompromiss durch? Mich hat ja eigentlich nur gestört, dass es nach einem Verbot klang, Objekte unter 100 m² detailliert einzuzeichnen. Dass Objekte über dem Wert als Flächen gezeichnet werden sollte, dürfte konsensfähig sein. --Tordanik 20:46, 19 August 2008 (UTC)
Ich bin da ganz leidenschaftslos. Nimm irgend einen Wert der Dir gefällt. Gruss, --Markus 20:56, 19 August 2008 (UTC)

Wiki-Änderungen zu impliziten Layern

Sorry Markus, aber ich muss mich mal wieder melden. Wie du vielleicht an meinen letzten Edits erkennst, bin ich mit deinem Versuch, implizite Layer für Brücken und Tunnel durch eigenmächtige Wiki-Edits durchzudrücken, nicht einverstanden. Die Antworten auf der Mailingliste haben ja wohl kaum Anlass zur Annahme gegeben, es bestehe auch nur annähernd ein Konsens in diese Richtung. Mit einer solchen Abweichung vom layer-0-Default erzeugst du nur Verwirrung und Uneindeutigkeit. --Tordanik 17:52, 12 September 2008 (UTC)

Hallo Tobias! Deine Beiträge habe ich bisher immer sehr geschätzt!
Danke für den Hinweis auf Deinen Edit (hätte ich sonst wahrscheinlich gar nicht bemerkt). Wenn Du eine Änderung - die als Verbesserung gedacht war - nicht gut findest, dann wünsche ich mir, dass Du das auf der [[Talk:De:Key:bridge]] dort begründest und wir dann gemeinsam eine Lösung finden. Beiträge anderer einfach zu löschen erzeugt unnötig Ärger. Gruss, --Markus 16:06, 13 September 2008 (UTC)
Dass ich nicht hinter deinem Rücken löschen wollte, erkennst du ja daran, dass ich dich hier informiert habe. In der von mir gelöschten Form war der Absatz aber schlicht eine falsche Tatsachenbehauptung: Es handelt sich nicht um eine „frühere“, sondern eine bis zum heutigen Tag in der deutlichen Mehrzahl der Fälle angewendete Art des Taggings. In einem solchen Fall obliegt m.E. die Begründung von Edits dem, der den status quo ändern will. Ich bitte dich also darum, die Gründe für deinen Änderungswunsch auf der von dir genannten Diskussionsseite darzustellen und mit mir und anderen Interessierten zu diskutieren. --Tordanik 18:16, 13 September 2008 (UTC)
*lach* "hinter dem Rücken" das hätte ich Dir ja auch nie zugetraut!
Aber ich habe nirgends geschrieben, dass das "Doppel-gemoppel-Tacking" nicht mehr angewendet würde, sondern dass es überflüssig sei. Und das habe ich genau durch den Text begründet, den Du diskussionslos gelöscht hast - irgendwie doof: meine Verbesserung steht jetzt ohne Begründung da...
Und ich habe nochmal darauf hingewiesen was wir alle wissen, aber hier missachtet haben:
wir arbeiten nicht für die Renderer. Gruss, --Markus 20:56, 13 September 2008 (UTC)
Diese Weisheit wird oft zitiert, aber auch sehr unterschiedlich interpretiert. Für mich bedeutet dieses Prinzip lediglich
  • dass wir mit Tags keine Anweisungen etwa zur Zeichenreihenfolge geben, sondern die Realität beschreiben (tun wir hier, die Brücke liegt über dem Fluss)
  • dass wir unser Tagging nicht an der Interpretation/den Bugs/den bereits implementierten Features des Renderers ausrichten, sondern an der Definition der Tags (ebenfalls gegeben)
  • dass wir nicht zugunsten von aussehenden Karten andere Anwendungen (Router & Co) benachteiligen und etwa Wege von der realen Position deutlich verschieben.
Im Zusammenhang mit Layers gibt es zwar öfters solches Renderer-Tagging – etwa Landuses mit layer, obwohl es sich nicht um physiche Features handelt, oder der als über dem Wald schwebend eingetragene See, bei dem der Mapper die multipolygon-Relation nicht kannte oder nutzen wollte – der Brückenfall zählt aber nicht dazu.
Denn ein Tagging für den Renderer liegt m.E. nicht vor, bloß weil vermeintliche Redundanz gegeben ist, oder bloß deshalb, weil eine Konvention den Programmierern Arbeit erspart – letzteres ist sogar sehr wünschenswert. Wenn ich mir die heutigen Diskussionen auf der ML so anschaue, scheint es als Universallösung für alles angesehen zu werden, dass der Programmierer ja alles schwer verwertbare – implizite Layer, die nirgendwo maschinenlesbar definiert sind, Schreibfehler in Straßennamen, Geschwindigkeitsangaben als Zahl, mit und ohne Leerzeichen, in Kilometer oder Meilen pro Stunde (korrigieren ist Zeitverschwendung und führt in die OSM-Diktatur!) – durch bessere Software abfangen kann. Kann er, aber wenn man es damit übertreibt, sollte man sich darauf einrichten, den Programmierer zu bezahlen, denn Spaß macht das Schreiben von „Ausputz“- und Filtercode statt neuer Features den meisten sicherlich nicht…
Es geht mir hier aber nur in zweiter Linie um die Programmierer – auch als Mapper finde ich es einfach alles andere als hilfreich, implizite Layer einzuführen. Beim „veralteten“ System weiß ich, woran ich bin: Ich klicke ein Objekt im JOSM an – wenn ein Layer da steht, gilt der, ansonsten ist er 0. So einfach, so leicht zu merken. Muss ich dagegen damit rechnen, dass irgendwer es „logisch“ fand, dass z.B. Skilifte automatisch Layer 1 sind (oder vielleicht sogar Layer 2, damit sie standardmäßig über Brücken gehen?), dann muss ich, um den Layer eines Objekts rauszufinden, im Wiki nachschlagen, was bitte die Defaults sind – oder einfach immer wie bisher Layer für alles setzen, um sicher zu gehen; nur muss ich das dann auch noch für die layer-0-Objekte tun – großartiger Fortschritt.
Langer Rede kurzer Sinn: Die expliziten layer sind kein Tagging „für die Renderer“, sondern ein Tagging für die sicher nicht wenigen Mapper, denen leicht zu merkende Regeln wichtiger sind als der „Aufwand“, eine 1 in das Layer-Presetfeld zu schreiben, und für Programmierer, ohne deren Anwendungen das ganze Projekt keinen Sinn hätte. Und wegen unserer abweichenden Interpretation des „wir arbeiten nicht für die Renderer“ kann ich eine Berufung auf dieses Prinzip auch nicht als Begründung für die Änderungen sehen. --Tordanik 22:11, 13 September 2008 (UTC)

Hallo Tobias, ich weiss gar nicht, wie ich das so erklären kann, dass Du es verstehst? Ich hatte eine Tante, die sagte immer "weisser Schimmel" - sie hat auch nie verstanden, weshalb das nicht notwendig ist und behauptete immer "wieso: ein Schimmel ist doch weiss?!"

Ich denke, wir sind uns einig: wir arbeiten nicht für die Renderer. Deine Beispiele (landuse etc) beurteile ich genauso wie Du. Solange wir zweidimensional zeichnen ist "default" immer "0", Wasser bedeckt das Land, bebautes Land bedeckt unbebautes. Und Brücken sind immer "oben drüber", Tunnel sind immer "unten durch". Das brauchen wir nicht nochmal zusätzlich sagen.

Wenn die Programmierer der Renderer es einfacher finden, wenn sie den Objekten beim Auslesen aus der DB einzeln sagen ob sie oben oder unten sind (weil es, aus was für Gründen auch immer, schwieriger sei dem Renderer einen entsprechende Regel für die ganze Objektklasse einzubauen), dann sollen sie das machen - aber eben nicht wir! Denn dann haben die Renderer die Verantwortung dafür, und können, falls ihr Programm mal eine allgemeine Regel gelernt hat, die Hilfskonstruktion wieder entfernen. Sie steht dann nicht durch uns in die DB gemeisselt (so wie bei meiner Tante).

Lass es mich nochmal am Beispiel "Skilift" erklären: Ein Skilift, eine Sessel- oder Seilbahn ist immer über der Piste. Genauso wie eine Überland-Hochspannungsleitung. Bei beiden wäre eine zusätzliches Attribut für "oben drüber" überflüssig. Erst wenn eine Hochspannungsleitung einen Skilift oder eine Seilbahn kreuzt, dann macht es Sinn, mit einem zusätzlichen Atribut anzugeben, was denn oben und was noch weiter oben ist. Aber eben nur dann, wenn zwei oder mehr solche "oben-drüber-Objekte" einander kreuzen.

Genau so ist es bei der Brücke... Gruss, --Markus 23:09, 13 September 2008 (UTC)

Ich denke schon, dass ich dich verstehe: Du findest, dass in der Realität Brücken etc. einfach immer über etwas drüber sind, und empfindest es deshalb als überflüssig, das noch hinzuschreiben.
Das ist nun zwar einfach dahergesagt, aber die Realität hält nicht automatisch in OSM Einzug, das muss jemand jeder einzelnen Software beibringen. Wenn ich mich jetzt daran machen würde, das in meinen Renderer einzubauen: Woher bekomme ich eine Liste der Oben-drüber-Objekte und Unten-Drunter-Objekte? Brücken über normalen Straßen über Tunneln, klar. Und Skilifte über Pisten. Aber schon bei den Skiliften und Hochspannungsleitungen wäre ich mir nicht so sicher, dass da alle daran denken werden.
Das ganze führt mit hoher Wahrscheinlichkeit dahin, dass die Renderer manches unterschiedlich interpretieren werden, und dass es auch die Mapper unterschiedlich interpretieren werden. Und wozu? Wo ist der praktische Vorteil? Layer abschaffen kann man deshalb noch lange nicht, es gibt ja die nicht eindeutigen Fälle, also muss das Tag trotzdem ausgewertet werden und den Mappern bekannt sein. Und wenn es nur um den layer=1 bei den Brücken geht, den kann man ja in die Presets packen, dann muss man ihn auch nicht mehr eintippen.
Bedenke: Wenn du in einer Gruppe unterwegs bist, in der es Großstädter gibt, die vielleicht nicht wissen, dass Schimmel immer weiß sind – dann wäre es zur Vermeidung von Missverständnissen wohl das kleinste Übel, einfach die Farbe des Pferdes dazuzusagen. Jedenfalls weniger Aufwand, als erst einmal jedem die Terminologie zu erklären. Besonders deshalb, weil immer wieder neue Großstädter dazukommen, denen man es noch einmal erklären muss, und es auch von den vorher Anwesenden vielleicht nicht jeder verstanden hat. „Weiß“ dagegen müssten sie eh kennen, weil es Dinge gibt, bei denen man ohne dieses Adjektiv nicht auskommt.
Ich bin mir übrigens ziemlich sicher, dass eine einzige Diskussion mit dir deine Tante mehr Zeit gekostet hat als alle „weißen Schimmel“ in ihrem Leben zusammengenommen. Insofern war das Attribut zwar nicht notwendig, aber es hätte eigentlich auch nicht weiter gestört… --Tordanik 09:42, 14 September 2008 (UTC)

Schichtenmodell und Rollen

Hallo Tobias, jetzt kommen wir der Sache näher. Du kennst ja die verschiedenen Schichtenmodelle, die auf verschiedenen Ebenen unterschiedliche Benutzerrollen bedienen. Bei OSM könnten das sein:

  1. Mapper und Anwender
  2. Kartografen und Webverantwortliche, Anwendergruppenverantwortliche
  3. Editorenübersetzer und Wikischreiber
  4. Editorenverbesserer, Anwendungs-Visionäre
  5. Editorenentwickler, Anwendungsentwickler
  6. Programmierer
  7. Datenbankspezialisten, Routingmathematiker, Wissensmanagementtheoretiker

Jede Ebene und jeder der in einer bestimmten Rolle an einer Ebene arbeitet, hat eine spezifische "Sicht auf die Welt" und auf deren "Repräsentation in OSM". Für jede Schicht und jede Rolle sind spezifische Fähigkeiten, Werkzeuge und Daten erforderlich. Und von jeder Ebene zur nächsten (Schnittstelle) braucht es effiziente Kommunikation, die auf valider Dokumentation beruht. Das Ganze ist von Ideen und daraus abgeleiteten Zielen bestimmt, die allen verständlich sein müssen. Zumindest soweit, dass sie in ihrer Rolle auf ihrer Ebene zielführend arbeiten können.

Kleine Projekte scheitern daran, dass sie beim Wachstum diese Erfordernisse missachten oder nicht umsetzen können.

Auch grosse stolpern immer wieder darüber, und setzen viel Geld in den Sand.

Zurück zur Brücke: Der Mapper und der Kartenleser weiss was eine Brücke ist. Es reicht, wenn er sagt: diese Linie ist eine Brücke. Was eine Brücke ist, muss "dem Programm" hingegen per Regel mitgeteilt werden, ebenso, was es tun soll mit so einem Ding. Aber das hat weder den Mapper, noch den Kartenleser zu kümmern. Ersterer soll sagen "Brücke" und letzterer soll wissen dass er zum Überqueren (normalerweise) keine Badehose braucht.

In OSM gibt es viel Unsinn, weil die angewendeten Regeln nicht kommuniziert und die Schichten vermischt werden. Denn der Mapper und der Kartenleser sind meist eine "Personalunion": als Mapper bildet er ein Stück Realität ab, und als Kartenleser will er diese wiederfinden. Dass dazwischen all die oben aufgeführten Schichten und Rollen einmal hoch und einmal runter durchlaufen werden interessiert ihn nicht. Er sagt "Brücke" - und wenn diese nicht angezeigt wird, dann fummelt er so lange an dem Ding rum, bis "der Renderer" ihm dieses anzeigt. Und das führt letztlich zu nicht beherrschbaren Rückkopplungen.

Deshalb die Erkenntnis: wir arbeiten nicht für die Renderer...

Oder anders ausgedrückt:

Wir müssen unterscheiden zwischen

wo
was
wozu

Wo = Länge, Breite, Höhe
Was = beispielsweise: Hängebrücke, max 2 Personen, Achtung: nicht schaukeln
Wozu = Schlucht überqueren

Und alles andere hat "irgendwie" im Hintergrund (Schicht 2..x) zu erfolgen.

Gruss, --Markus 10:43, 14 September 2008 (UTC)

Und jetzt wünsche ich mir nur noch eine Lösung für das "irgendwie". Woher ein Programmierer/Mapstyledesigner effizient (ohne das ganze Wiki zu lesen) erfahren soll, welche „natürliche“ Höhenordnung er Objekten zuweisen soll, um mit den Vorstellungen der Mapper und den anderen Anwendungen übereinzustimmen – diese beiden Ziele sind in schwierigeren Fällen als „Brücke“ wohl kaum mehr durch Einbau seiner eigenen intuitiven Annahmen erreichbar.
Bisher gibt es für das "irgendwie" kein praktikables Konzept. Bereits jetzt mal eben das Wiki zu ändern, führt zu genau dem, was wir nicht wollen: Mapper taggt so, wie er es gelesen hat. Irgendein Renderer malt die Schlucht über die Brücke. Mapper fummelt so lange an der Brücke rum, bis der Renderer ihm alles passend anzeigt …
Daher ist das Vorgehen meiner Meinung nach: Erst Lösung für Problem anbieten, dann Mapping-Tipps ändern. Nicht umgekehrt. --Tordanik 11:42, 14 September 2008 (UTC)
"Irgendwie" bedeutet, dass das durch Kommunikation zwischen den Schichten 2 bis x ausgehandelt wird (aber damit eben nicht sie Anwender belastet werden). Bei so eindeutigen Dingen wie Brücke" ist das aber eigentlich auf allen Ebenen "common sense", nur die Ausnahmefälle müssen noch beschrieben und geregelt werden.
Bisher gibt es für die Regelbildung und deren Kommunikation überhaupt kein Konzept. Deshalb gibt es ja so viel Orakeln und Missverständnisse. Solange Regeln nicht kommuniziert werden werden Chaos und Reibungsverluste zunehmend grösser.
Ich habe an einer kleinen Ecke auf die Zuständigkeiten hingewiesen, sie etwas zurechtgerückt, dies begründet. Du hast die Begründung gelöscht. So entsteht keine Veränderung. Die Aufgabe der Renderer wird nun nach wie vor auf die Anwender abgewälzt. Wir haben zwar ein "Credo", aber wir handeln nicht wirklich danach. Gruss, --Markus 17:13, 14 September 2008 (UTC)
Das Zuständigkeiten-Problem löst man nicht, indem man den Mappern sagt „ab sofort schreibt ihr das nicht mehr hin, das sollen die da oben mal machen“, wenn die da oben auf Grund fehlender Konzepte nicht dazu in der Lage sind. So etwas geht nicht von heute auf morgen, und Rücksichtnahme sollte jedem Teil der Community entgegengebracht werden. Der einzige „Erfolg“ deines Vorgehens wären wohl verärgerte Mapper, wenn das Rendering nicht funktioniert, obwohl es doch im Wiki steht. Leuten quasi zu befehlen („Don’t use“), layer nicht mehr zu benutzen, und die Erscheinung aus Wunschdenken heraus hin die ferne Vergangenheit zu formulieren („Früher …“), ist einfach unangebracht. Einen freundlichen Hinweis, dass die jetzt noch übliche Layerangabe hoffentlich bald nicht mehr nötig sein wird, hätte ich dagegen nicht entfernt, und ich bitte dich daher auch jetzt darum, einen solchen Hinweis an Stelle der von mir gelöschten Absätze unterzubringen. --Tordanik 19:23, 14 September 2008 (UTC)

Hallo Tobias, wir behandeln drei Ebenen:

a) die Brücke
b) die Modelle, Schichten und Rollen
c) die Metakommunikation darüber, wie a und b zusammenhängen und wie man Veränderung bewirkt.

Für mich war "die Brücke" nur Stein des Anstosses. Darüber habe ich entdeckt, dass "alle für den Renderer arbeiten", obwohl sie das gerade nicht tun sollen. Deshalb hatte ich bei "Brücke" geschrieben, dass layer ein Überbleibsel aus "alten Tagen" ist, und dass die Renderer heute gut ohne auskommen können (wenn sie es denn wollen täten). Klar, wenn die Renderer nun nicht reagieren, dann sind die Mapper geneigt, wieder zum "Altbewährten" Zuflucht zu nehmen, und es hätte sich nichts geändert.

Es ist also die Frage zu beantworten, wie denn in so einem OpenSource-Projekt Änderungen zustande kommen und initiert werden können. Ich sehe da ähnliche Schwierigkeiten wie bei Behörden oder behördenähnlichen Konzernen: "das haben wir immer so gemacht" sind dort übliche Killerphrasen. Weisst Du, mir geht es nicht um einzelne Formulierungen, da bin ich (wie im anderen Beispiel auch) ziemlich leidenschaftslos. Wenn Du also eine Formulierung weisst, die besser geeignet ist als meine, um die erwünschte Veränderung (und Vereinfachung für die Mapper) bewirkt, und gleichzeitig die Renderer dazu bewegt mitzugehen: nur zu! Gruss, --Markus 10:58, 15 September 2008 (UTC)

Vorgehen

Ich denke, wir kennen inzwischen unsere Standpunkte. Meine Annahme ist: Ich glaube, dass keine Fomulierung hier im Wiki geeignet ist, die Renderer dazu zu bewegen, diese Veränderung vorzunehmen, und lehne deshalb jede Formulierung ab, die die Mapper zu dieser Veränderung veranlasst, bis die Renderer-Verantwortlichen auf andere Weise zu dem Schritt bewegt wurden.
Meine Methode, das zu etablieren, wäre: Sowie wir standardisierte, automatisiert anwendbare Implikationen haben – ein m.E. nötiger Fortschritt, für den dieses Problem hier, da es ja kaum als solches gesehen wird, als Anstoß aber ungeeignet sein dürfte –, würde ich versuchen, per Proposal ein stets nur impliziertes (also nie von Mappern verwendetes, aber bei ausdrücklicher Verwendung des Layers nicht in die Quere kommendes) sublayer-Tag einzuführen. Zum jetzigen Zeitpunkt, mit kaum formalisierten Implikationen, würde das aber mit höherer Wahrscheinlichkeit scheitern. --Tordanik 20:32, 17 September 2008 (UTC)

Klingt interessant! aber was heisst das konkret? Was meinst Du mit: "formalisierte Implikation"? Was für ein "sublayer-Tag" willst Du einführen? Gruss, --Markus 21:22, 17 September 2008 (UTC)

Mit „formalisierte Implikation“ meine ich folgendes: Im Moment steht auf manchen Key-Seiten ein „Implies:“ in dem grünen Kasten, manchmal mit ein paar Tags dazu. Beispiel auf highway=steps – dort steht als Implikation access=no und foot=yes. Das bedeutet, dass man als Mapper nicht mehr dazuschreiben muss, dass Treppen für kein Verkehrsmittel außer Fußgängern geeignet sind – es ist eben nun einmal eine Treppe. Da die dort genannten Tags impliziert sind, sollte es für eine Anwendung auch absolut keinen Unterschied machen, ob man es hinschreibt oder nicht, nur abweichende Infos würden die Vorgaben natürlich überschreiben.
Diese Implikationen an irgendeiner Stelle in standardisierter Weise hinzuschreiben, hat nun zwei Vorteile:
  1. Solche Zusammenhänge sind einem Mapper zwar im Normalfall klar (wie die Farbe eines Schimmels eben), so dass er intuitiv richtig mappt, aber wenn er sich doch mal unsicher ist, kann er sie leicht nachsehen.
  2. Prinzipiell muss ein Programmierer dann nicht jede solche Selbstverständlichkeit seinen Programmen eigenhändig beibringen. Hätten wir diese Informationen schon irgendwo in automatisiert lesbarer Form vorliegen (etwa als XML-Dateien oder vielleicht sogar Datenbank – das meinte ich mit „formalisiert“), dann könnten sie vor der Verarbeitung durch etwa einen Router von diesem automatisiert eingepflegt werden – vor der Verwendung würden dann also alle Treppen automatisiert mit foot=yes versehen, alle Autobahnen mit foot=no und so weiter (wieder vorbehaltlich ausdrücklich anders getaggter Fälle, natürlich). Damit ist sofort garantiert, dass die Anwendung genau die richtigen Wege etwa fürs Fußgängerrouting heranzieht – selbst solche, von denen der Programmierer noch nie gehört hat, weil sie etwa eine lokale Besonderheit eines anderen Landes sind.
Insgesamt bedeutet das: Sobald dieselben Implikationen, die dem Mapper (so sie ihm nicht sowieso intuitiv klar sind), gezeigt werden, auch von den Anwendungen automatisch und unverfälscht übernommen werden, ist sichergestellt, dass es diesbezüglich keine Missverständnisse und Widersprüche zwischen Mappern und Anwendungen sowie Anwendungen untereinander mehr gibt.
Was zum Erreichen dieses Zustands fehlt, ist eben vor allem ein Datenformat für die Implikationen, das dann auch von anderen Anwendungen verwendet werden kann. Ich hatte ja mal vor, einen experimentellen XML-Extraktor zu schreiben, der die Infos aus dem Wiki übernimmt (um festzustellen, ob das so geht, wie ich es mir vorgestellt hatte), aber da bin ich noch nicht dazu gekommen.
So, und die Erklärung für sublayer schiebe ich morgen nach, hab leider grade keine Zeit mehr. :) --Tordanik 22:20, 17 September 2008 (UTC)
Nun, hatte gestern keine Gelegenheit zum Antworten und auch heute nur wenig, also nur kurz die Grundidee zum sublayer: Nutzereinträge sollten immer Vorgaben überschreiben. Wenn ich jetzt zwei sich kreuzende Brücken habe und eine davon auf Layer 1 setze, dann will ich, dass sie über die andere geht. Wird aber nicht funktionieren, wenn die automatisch ein Layer 1 zugewiesen bekommen hat, denn Überschreiben von Vorgaben funktioniert nur auf dem Objekt, das den ausdrücklichen Tag bekommt.
Lösung: Brücken bekommen nicht automatisch layer=1, sondern sublayer=1, layer bleibt für alle Features, bei denen der Mapper es nicht ausdrücklich gesetzt hat, 0. Der Mapper setzt den Sublayer niemals selbst. Wenn zwei Features unterschiedlichen Level haben, werden diese für die Höhenabstufung verwendet, nur wenn zwei Elemente auf dem gleichen Layer sind, kommen die sublayer zum Tragen.
Zusätzlicher Bonus: Da sublayer ein eigenes Tag ist, lässt es sich leichter mit den etablierten Verfahren (Proposal) einbringen.
Insgesamt handelt es sich also dabei nur um ein Konzept, das „Brücke geht immer über etwas“ transparent zu gestalten. Der Mapper braucht davon nichts zu wissen, ihn interessiert nur, dass es funktioniert und Brücken immer über normale Straßen geführt werden, wie er es erwartet.
--Tordanik 20:20, 19 September 2008 (UTC)

Hallo Tobias, da bin ich ganz bei Dir:

Die Definition der Schlüssel muss möglichst eindeutig sein. Dazu gehört die genaue Beschreibung von:

  • Inhalt des Schlüssels
  • mögliche Werte und deren Bedeutung (muss, kann, darf nicht)
  • Regeln (Implikation, Explikation, Unter-Schlüssel)
  • Unter-Schlüssel
  • mögliche Relationen
  • Renderer-Regeln (oder Link dorthin)

Selbstverständlich muss eine solche Beschreibung zentral erfolgen, sinnvollerweise in einer DB, die auch die Übersetzungen verwaltet, und auf die Anwendungsprogramme direkt zugreifen.

Das was Du mit "sublayer" beschreibst gilt m.E. immer: alle Regeln (für Attribute und Werte) gelten immer so lange, bis sie individuell überschrieben werden. Übergeordnet ist abber immer eine Regel, das überschrieben werden darf und was nicht.

Der Anwender erfährt von dem Ganzen immer nur so viel, wie es ihn gerade situativ betrifft (oder kann bei Interessen alles in der Doku lesen).

DAS alles wäre dann wirklich ein Kulturwandel! Gruss, --Markus 10:27, 22 September 2008 (UTC)

Verein

"...und einstimmig entscheiden." Warum? Das ist IMHO utopisch, wenn natürlich auch wünschenswert. --Avatar 11:05, 15 September 2008 (UTC)

Hallo Avatar, einstimmige Entscheidungen haben den Vorteil, dass sie meist sehr gründlich vorbereitet sind und solange optimiert werden, bis jeder wirklich dahinter steht - und das finde ich wie Du wünschenswert. In einem kleinen Kreis (7 Mitglieder) ist das durchaus möglich. In der indianischen Kultur wird das in noch viel grösseren Gruppen praktiziert. Gruss, --Markus 11:16, 15 September 2008 (UTC)

Language Template

I've had a go at getting the Language Template working correctly. See: En:Test. For EN, if an En:Page is found it is used, else Page.

"bridge" with a layer

Hi Markus, no I didn't write any specific comments in the Map Features (or rarely). But you see my name in most of the templates history because I migrated the big Map Features single page into smaller wiki templates in order to support the same "Map Features" page in multiple languages. I didn't change anything in the content itself at that time. That's why you see my name in the history but to find the original writer, you should look in the history of the main Map Features wiki page itself (before I split in templates in January 2008). Regards. Pieren 10:51, 15 October 2008 (UTC)

ok, thanks! --Markus

Sprachversionen

{{Template:LanguageTest|PageTitle}}
See this diff, please let me know if you think it's suitable. - Firefishy 08:23, 10 October 2008 (UTC)
Thanks! please give me a week for check it. --Markus 17:06, 10 October 2008 (UTC)

Tag forest

Hi Markus, I see that you recently edited the landuse forest tag in the wiki. I would like to hear your comments about the fact that the page Forest says that landuse=forest and natural=wood should never be used together and the fact that most of the german forests are using both tags together... -- Pieren 13:29, 23 October 2008 (UTC)

Hallo Pieren, Du kannst deutsch mit mir sprechen. Was genau ist Deine Frage? Wenn Du einen Bot schreiben kannst, der alle deutschen Wälder auf landuse=forest ändert und alle "layer" löscht: nur zu! Gruss, --Markus 13:42, 23 October 2008 (UTC)

Hallo Markus, ein solcher landuse=forest-Bot sollte aber irgendeine Art Kennzeichen kennen, damit er weiß, daß bestimmte natural=wood-Angaben bewußt gesetzt worden sind. Beispielsweise gibt es in NRW sogenannte Naturwaldzellen, in denen keine Forstwirtschaft betrieben wird, also natural=wood anstatt landuse=forest, siehe z.B. http://www.openstreetmap.org/?lat=51.6744&lon=6.3637&zoom=14&layers=B000FTF. 18:19, 7 December 2008 (UTC)SaschaR

Hallo Sascha, es gibt viele verschiedene Waldarten, aber bisher nur zwei OSM-Attribute. Für Naturwald muss man einfach ein drittes erfinden. Gruss, --Markus 18:29, 7 December 2008 (UTC)

ele vs. alt

Hi Markus, schau doch bitte bei Gelegenheit noch mal bei DE talk:Altitude vorbei. Gruß, -- Schusch 21:15, 12 January 2009 (UTC)

de:Altitude ist eine Antwort auf das unsinnige "ele" (wo "Höhenangaben" ohne irgendwelchen Bezug auf eine Referenzhöhe gemacht werden), damit WGS-84 zugrunde gelegt werden kann. Gruss, --Markus 08:07, 13 January 2009 (UTC)

Zoom Levels

Hallo Markus!

Soweit ich das richtig erkannt habe, hast du diese Seite http://wiki.openstreetmap.org/wiki/Zoom_levels erstellt. Ich wollte mit MapOf Maps downloaden, wobei mir einige Fehler in der Liste aufgefallen sind. Neben den Koordinaten von latitude und longitude und dem zoom level gibt man in die url auch die Pixelbreite und Höhe der map mit an. Da ich eine map downloaden wollte, die anhand eines Radiuses eine gewünschte Breite und Höhe hat, habe ich deine Tabelle benutzt um die Breite in Pixel anhand meines Radiuses zu berechnen. Leider kam das überhaupt nicht hin. Ich habe aber nun eine neue Tabelle mit den richtigen Werten errechnet und wollte fragen, ob du sie haben willst bzw. ob diese Tabelle überhaupt dafür vorgesehen war eine Umrechnung von Meter in Pixel zu gewährleisten?

Gruß Daniel

Hallo Daniel, ich muss gestehen, dass ich auf die Schnelle nicht mehr weiss woher ich die "m/Pixel" habe. Bezieht sich wohl auf die Bildschirmdarstellung von Mapnik (beschreibt die mögliche Genauigkeit bei der Darstellung), aber die wäre ja abhängig von weiteren Parametern. Da ich die nächsten Zeit nicht online bin, kann ich nichts näheres dazu sagen. Sorry dass ich die Doku damals nicht geschrieben habe - jetzt haben wir die Verwirrung...
Zu dieser Seite passt auch Genauigkeit von Koordinaten.
Breite und Höhe eines Bildschirmfensters, beispielsweise um eine Karte anzuzeigen, oder als Parameter in einer URL zum Herunterladen von Daten, ist aber etwas anderes. Mach doch dazu einfach eine weitere Wiki-Seite und dokumentiere genau, was sie bedeutet, und verlinke sie auf den anderen zwei Seiten. Gruss, --Markus 08:23, 13 May 2009 (UTC)

Stop creating empty FR: pages

Please stop creating FR: empty pages with the comment "please translate". It doesn't help. The French group knows where the original pages are and that we need some resources to translate them. We also have enough pages which are only partially translated or pages which are translated from 2 years old content. Creating the empty page makes the illusion in the language bar that the translation exists... -- Pieren 08:13, 23 June 2009 (UTC)

Yes Pieren, I know this. We prepare only the links we uses in JOSM in de, fr, en, for not to get a non existing page (there are only a few). Of course we hope that they well be translated soon. --Markus 17:50, 23 June 2009 (UTC)

whitewater maps

Hi, I see you created a German version of the whitewater maps project page. Could you add a note asking any contributors to add rivers they have mapped to the list of rivers on the English page?

Done. Thanks for the hint. --Markus 20:06, 19 July 2009 (UTC)

Anmerkung zu deiner Seite des Seamap-Editor

Hallo Markus, ich habe gerade eine Anmerkung zu deiner erstellten Seite des Seamapeditors geschrieben. Ich wollte nicht einfach deine Seite bearbeiten, da ihr die Angelegenheit wahrscheinlich eh schon auf dem Schirm habt, aber schau bitte mal drüber. DE_talk:Seamap-Editor --Christian

Grenzsteine

Moin Markus, ich hab hier mal einen Vorschlag zur Kennzeichnung von Grenzstein in Funktion gemacht, Verbesserungen und Erweiterung wären prima :-) (du hast sicher ein paar Vorschläge bzgl. amtlicher Gültigkeit, vielleicht gibt es auch eine bessere Auszeichnung, die in ein schon vorhandenes Schema passt ...). Damit der Vorschlag nicht untergeht habe ich an den entsprechenden Stellen darauf hingewiesen. Gruß, -- Schusch 10:16, 31 August 2009 (UTC)

Marine Mapping Proposal

Same message copied to User:Nop Hi Markus,

I'm doing a bit of work on tidying up the Wiki and noticed your comments on Proposed_features/marine-tagging#Voting. Any chance you could direct me to the existing Key, Tag or Feature page for what you say is the current implementation of what this proposal duplicates? I've not had much luck by searching, and am trying to work out how the pages Harbour and Marine Mapping correlate.

Martin Renvoize 17:54, 13 December 2009 (UTC)

Hallo Markus!

Bist Du der Markus, der bei OpenSeaMap|FAQ unter Wie kann ich mitmachen? als Ansprechpartner für

  • Grafiker,
  • Hafenkapitän, Marinabetreiber, Reeder, Vercharterer
  • Ozeanograf, Kartograf, Bathymeter, Meteorologe

angegeben ist? Wenn nicht, wie kann ich ihn ansprechen? Der dortige Link funktioniert nicht, da ich meine Mails bei gmx online abrufe... - u. eine email-adr ist nicht angegeben.

HG, --Skipper Michael 20:54, 16 January 2010 (UTC)

Hallo Michael, Du kannst mich auch über OSM-Wiki-Mail erreichen. Gruss, --Markus 15:03, 17 January 2010 (UTC)

Landesamt für Vermessung und Geoinformation (Bayern)

Hallo Markus, wie ich dem Nutzungsvertrag entnommen habe, warst du (einer) der Initiator(en) des Luftbilder aus Bayern-Projekts. Da die Seite seit Juni 2009 nicht mehr aktualisiert wurde, wollte ich mal nachfragen, ob es irgendetwas neues gibt. Zum Beispiel ob es eine Rückmeldung auf den „Projektbericht an die Regierung“ gibt. Grüße, Michael --Michael_K ¿! 00:14, 19 January 2010 (UTC)

Hallo Michael, bitte frage mich im Februar nochmal per Mail, dann werde ich nachfragen. Gruss, --Markus 08:00, 19 January 2010 (UTC)
Hallo Markus, leider hab ich deine eMail-Adresse nicht. Wenn du mir ne (leere) Mail an „osm (.at.) michael-kaeufl (dot) de“ schickst, dann hab ich sie und frag im Februar per Mail nach. --Michael_K ¿! 09:53, 19 January 2010 (UTC)

Smokefree

Hallo,

Du hast bei Restaurants einfach den Tag "smokefree" dazugeschrieben.

Das haut so nicht hin. Wir brauchen ein Proposal, damit wir

  • Nichtraucherrestaurants
  • Restaurants mit getrennten Bereichen für Raucher und Nichtraucher
  • Restaurants mit nicht baulich getrennten Bereichen für Raucher und Nichtraucher
  • Raucherkneipen

auseinanderhalten können.

Willst Du das mal machen? Brauchst Du Hilfe? --Lulu-Ann 12:35, 28 May 2010 (UTC)

Ich seh grad, gibt's schon: smoking. --Lulu-Ann 12:36, 28 May 2010 (UTC)

Hi, danke für Deine Hilfe! habe im Proposal in die Disku geschrieben. Du hast doch viel Erfahrung in der Formulierung von Proposals - vielleicht kannst Du smokefree=yes irgendwie einbauen oder ein Proposal dafür machen? Wir sehen uns in Lüneburg? Gruss, --Markus 15:10, 28 May 2010 (UTC)

Kayak mapping

Just spotted this picture: File:Kajak and OSM.jpg Is that you Markus? What was this event? -- Harry Wood 17:22, 5 July 2010 (UTC)

Hi Harry, no, I was only the photographer and OSM-promoter. It was an Outdoor-Sport-Exhibition with free kajaking for the visitors on a nice small river. Some tags we discussed there with the kajak-professionals I have written here.
Do you know OpenGastroMap.org? you can edit it in z=18. --Markus 22:18, 6 July 2010 (UTC)
OpenGastroMap.org ? no. Is it showing pubs and restaurants which allow smoking? Are the edits gathered in a list to be moderated/uploaded by someone? -- Harry Wood 11:03, 7 July 2010 (UTC)
Hi Harry, see the Projectpage (english/german) and https://jira.toolserver.org/browse/ACCAPP-186. Yes we collect the edits and load it up daily. --Markus 11:37, 7 July 2010 (UTC)

page *

hi. you create a page *. is it necessary?--Dr&mx 22:33, 3 June 2011 (BST)

Hi! it is a workaround for values behind "*" in tags.
May be you like to translate it to English?
Thanks for cleaning the wiki! --Markus 13:17, 4 June 2011 (BST)
uff - my template:Languages seems not to work right here...
it need all translates on the page?--Dr&mx 13:37, 4 June 2011 (BST)
no - but English would be fine. --Markus 13:46, 4 June 2011 (BST)

Höhendaten aus GPS-Tracks

Hallo Markus
Du hast im März auf [1] berichtet:
Derzeit laufen Versuche, mit statistischen Methoden aus ainer grossen Menge von Höhendaten aus GPS-Tracks ein eigenen Höhenmodell zu erstellen, bzw. damit das SRTM-Modell für uns zu verfeinern.
Wir arbeiten gerade an einer Fahrrad-Nagivations-App und wären sehr an der Integration von Höhendaten interessiert, die aber genauer sein müssten als die SRTM-Daten.
Ich bitte um weitere Infos bzgl. dieser Versuche, vielleicht können wir da zusammenarbeiten. Wir möchten nicht das Rad neu erfinden, zumindest nicht in dieser Hinsicht :-)
Didi X3 19:06, 29 November 2011 (UTC)

Danke für die Internationalisierungs-Stubs

Markus, danke für die Mehrsprachigkeit in der OpenSeaMap auf iOS-App Seite. Hab mal die englische Übersetzung hinzugefügt. --Trailblazr 12:00, 3 February 2012 (UTC) ... und die französische. App ist grade auf frnz. und engl. auch neu eingerteicht bei Apple. --Trailblazr 03:48, 4 February 2012 (UTC)

Mainnav GPS

Moin Markus, du sach mal, du hast auf der Seite einfach mein Template entfernt, was vielleicht etwas zu kurz gedacht war. Mit dem Template sammeln wir demnächst alle Informationen zu GPS Geräten zusammen, von daher wird es noch benötigt. Die Konvention ist eigentlich, dass die Seite so heißt wie der Hersteller (Ausnahmen sind z.B. Garmin, wo es auf Familien-Ebene nochmals unterteilt wird). Daher mache deine Änderungen bitte rückgängig und pflege deine Informationen am besten mit ein. --!i! This user is member of the wiki team of OSM 07:21, 29 March 2012 (BST)

DE:Wanderweg

Hallo Markus. Ich schlage vor den Abschnitt Westerwald aus DE:Wanderweg nach Talk:WikiProject_Germany/Wanderwege-Netz zu verschieben. Auf dieser Seite befindet sich bereits eine Liste von Wandervereinen. Ich denke wir müssen auf DE:Wanderweg nicht eine zweite Liste anfangen. --Rudolf 09:05, 2 April 2012 (BST)

Sehe ich genauso. Oder gleich auf die Artikelseite :-) Gruss, --Markus 12:02, 4 April 2012 (BST)
Ich habe deinen Beitrag verschoben und für DE:Wanderweg eine Löschung vorgeschlagen. Gruß Rudolf --Rudolf 05:53, 7 April 2012 (BST)
Danke. --Markus 11:37, 18 April 2012 (BST)

INT 1 symbols

Hi Markus. I have more or less completed documented all INT 1 map symbols with their corresponding OSM tags. I think it is now time for us to make some form of informal online workshop, to start unifying the tagging schemes between OpenSeaMap, FreieTonne and other suggestions, and let us document all used tags. I am also in paralell with this trying to create a complete INT 1 tagging preset for use in JOSM, in paralell with the OpenSeaMap plugin maybe. To let us continue to make the best free nautical map in the world we need to unify our tagging, so that we can work all together instead of each on his own little project. See User:Skippern/INT-1 --Skippern 02:57, 1 September 2012 (BST)

Checking with Google Earth

Hello Markus. For reference, Google Earth data is not compatible with the OSM licence. Please don't advocate cross checking or copying data between the two. I have reverted your edit to the Key:seamark:fixme article. Please see the import guidelines and the licence for more details. --Dee Earley 15:20, 7 December 2012 (UTC)

Hello Dee, thanks for thinking about "how to get informations". I confirm: Google data is not free and regrettably not usable for OSM.
The words you did delete are part of a big quality improvement project. May be my English is not good enough and my words are mistakable? I do not recommend to use Google coordinates. For locations we use Bing :-)
But for improving our informations, we use all help we can need. If I have a photo, the background can help to distinguish and verify my guess. Especially for lighthouses, you can see in aerial photos a long shadow of the tower, which says: here about is the tower. The exact coordinate, you can then get from Bing :-)
May be you can write this in more understandable words? In the meantime I rewrite it as it was.
Thanks, --Markus 08:39, 9 December 2012 (UTC)
PS: what is your interest in lighthouses? Are you a sailor?
You didn't explicitly say "use Google coordinates", you say (after reverting my reversions), "Use Google Earth to check the position of the beacons" (or "Benutze Google Earth um die Position der Leuchtfeuer zu prüfen"). As I said before, their data is not free and MUST NOT be used in ANY way to add, confirm, update or correct OSM data. Even if you're looking at pictures you've found through Google Earth, they are under their own licence and you MUST check whether they are compatible or not. DO NOT advocate using data from Google under any circumstance or your account will be disabled on both the wiki and OSM itself. --Dee Earley 22:39, 9 December 2012 (UTC)
To Clarify, I have no problem with any of your contributions, just your use and advocation of the use of VERY off limits data sources for "checking of data". To other, less experienced users, there is no difference between "checking images I found via Google Earth" and "checking the imagery I found in Google Earth". Also, you say all your edits are considered public domain. Be very careful this only refers to stuff you got from public domain sources, as traced data is most definitely NOT public Domain. --Dee Earley 22:59, 9 December 2012 (UTC)

Hello Dee, of course it is allowed to watch pictures and to use the visual content for approving your own mind. This is the purpose of pictures! By the way: I don't like Wikipedia-like "edit wars"... So please help to improve my English and don't delete content. --Markus 13:46, 21 December 2012 (UTC)

OSM Website für Gemeinde

Hallo Markus,

was ist eigentlich aus dem Projekt DE:OSM_in_Website_für_Gemeinde bei der Gemeinde Simmelsdorf geworden?. Ich würde gerne ein paar Gemeinden zwecks Datenspende anschreiben und hätte dann gerne ein Beispiel angefügt, wie die Gemeinde im Gegenzug auch Nutzen aus der Datenspende ziehen kann. Leider ist auf der Gemeindeseite von Simmelsdorf unter Ortsplan nur ein externer Link auf 1001Stadtplan des Städte-Verlags zu finden. Unter Über Simmelsdorf - Lage und Umgebung kommt nur eine Seite mit dem Hinweis, daß es z.Zt. keinen Inhalt gibt. Ansonsten habe ich Links auf Seiten gefunden, die es nicht gibt oder die es nur als Rahmen aber ohne Karteninnenleben gibt. Eine diesbzgl. Anfrage auf der Diskussionsseite zu Status Projekt Simmelsdorf - Aktualität Links und Inhalte blieb leider ohne Antwort. Da Du wohl an dem Projekt beteiligt warst, kannst Du mir diesbzgl. vielleicht weiterhelfen. LG --Rennhenn (talk) 16:56, 16 June 2013 (UTC)

Hi, nimm als Beispiel Rostock, Neunkirchen am Sand, oder Lauf an der Pegnitz. Simmelsdorf hat keine Daten gespendet, und hat auch lieber das spärliche Steuergeld einem kommerziellen Verlag-Werber in den Rachen geeschmissen ;-) Gruss, Markus

Hallo Markus, dürfte ich Dein Banner (http://wiki.openstreetmap.org/wiki/File:OSM-Banner.png) als Tiff in möglichst grosser Auflösung haben. Ich würde es gerne ein bisschen Anpassen (lokalisieren für unsere Gemeinde) und für den 9. August an unserem Haus aufhängen.. freundliche Grüsse Roman rhaerdi@gmx.ch P.S.: Ich hoffe Du siehst, dass ich hier etwas geschrieben habe? - Ich wusste nicht wie ich Dich sonst kontaktieren könnte??

Ist unterwegs :-) Gruss, --Markus (talk) 17:38, 16 July 2014 (UTC)

DE:CartoCSS

Hi Markus, danke für deine Teilübersetzung von DE:CartoCSS. Leider musste ich vorerst einen Teil entfernen – siehe bitte die Versionsgeschichte. Wir sind doch ein freies Projekt, mit freien Lizenzen – dann sollten wir sie auch selbst achten. Du kannst gern hier, oder auf der zugehörigen Talk-Seite antworten. Dank dir! Viele Grüße --Aseerel4c26 (talk) 22:07, 6 September 2014 (UTC)

Hallo, Ich schätze engagierte Mitareit bei OSM sehr, auch Deine. Aber "Löschen" von Beiträgen anderer ist übergriffig und wirkt immer agressiv. Sowas widerspricht dem Stil von OSM. Wikipedia leidet seit Jahren unter solchen Praktiken (siehe dort). Bitte unterlasse solches! Verbesserungen sind hingegen immer gern gesehen :-) Mit herzlichem Gruss, --Markus (talk) 07:06, 7 September 2014 (UTC)
Ich habe aus Vorsicht vorerst den unklar lizenzierten Text entfernt. Was soll daran dem Stil von OSM widersprechen? Verstehst du meine Begründung nicht? Ich versuche es dir gern zu erklären. Leider hast du nun ihn einfach ohne Kommentar wieder reingestellt. Sinnvoll wäre ein Kommentar unter welcher Lizenz der fremde Text steht und wo man jene Lizenzerklärung nachlesen kann.
Was ich hingegen als "agressiv" empfinde ist das Titulieren (ehemalige Überschrift auf meiner Talkseite) meiner Hilfe als "Löscheritis" (ein negatives Wort). Muss das sein, nein, oder? --Aseerel4c26 (talk) 13:26, 7 September 2014 (UTC)
Ach Markus, du ignorierst meinen Hinweis auf die lizenztechnische Problematik also oder hast du meine Nachricht hier übersehen? Wie auch immer ich habe keine Lust mich hier mit dir herumzustreiten und ignoriere es halt auch. Soll sich eben jemand anderes drum kümmern. --Aseerel4c26 (talk) 21:46, 7 September 2014 (UTC)