User talk:Cmuelle8/Archive

From OpenStreetMap Wiki
Jump to navigation Jump to search

Seite von Zwenkau

  • Hallo Christian, hier ist noch einer :-) Ich hab mal eine Seite für Zwenkau angelegt. Sieh mal zu, dass Du auf die Userliste (Category:Users_in_Zwenkau) kommst! --Cheinema 19:06, 18 June 2008 (UTC)

Key:area

I reverted http://wiki.openstreetmap.org/w/index.php?title=Key:area&diff=1107254&oldid=1106171 - see http://wiki.openstreetmap.org/wiki/Talk:Key:area#barrier.3Dhedge_on_a_closed_way_in_default_map_style Mateusz Konieczny (talk) 13:40, 29 November 2014 (UTC)

DE:Tag:information=guidepost

Ich halte das überhaupt nicht für gelungen, was du dort auf eigene Faust durchzudrücken versuchst.

  1. Diesen Vorschlag gibt es in keiner anderen Sprachversion. Taginfo zeigt dann auch, dass der Guidepost-Key für alles Unmögliche verwendet wird, aber praktisch nicht dafür.
  2. Es gibt Wegweiser, die sowohl Schilder für Radfahrer als auch für Wanderer enthalten. Da müsste man dann wieder Semikolon-Listen einführen, die auswertungstechnisch bescheiden sind.
  3. Auch der Rest mit den Directions ist in keiner Form sinnvoll normiert und wurde im Forum als völlig ungeeignet angesehen. Zumal das auch redundant zu DE:Relation:destination_sign ist.

Das ist also völlig ungar in der jetzigen Form und auch kein zukunftsfähiges Modell. Es ist deshalb nicht sinnvoll, das im Wiki weiter als Schema aufzuführen und damit Leute für die Ablage P taggen zu lassen. --Kontinentalverschieber (talk) 13:59, 22 August 2015 (UTC)

Ungar war das, was guidepost=* vorher proklamierte, da wurden Werte völlig verschiedener Kategorien zusammengemischt
Diesen Unsinn lässt du stehen, weil du ihn für 'gelungen' hältst? Na Prost, Mahlzeit.
Relationen sind etwas für Fortgeschrittene/Eingearbeitete und nicht in jedem Fall notwendig. Wer klein anfängt, Daten zum Projekt beizusteuern, für den sind direction_*=* eine einfache, plausible und auch richtige Art, mitzumachen. Ob das auch mittels Relationen darstellbar ist, ist dabei ebenso nebensächlich, wie das Argument der Redundanzvermeidung. Es gibt in den OSM-Daten eine ganze Menge Redundanzen und nicht immer sind sie schädlich oder unerwünscht. Wer etwas nicht braucht, dem hilft die Toolchain, Daten zu filtern und zu selektieren - sehr komfortabel seit einiger Zeit mit Overpass und Overpass-Turbo.
Für kombinierte Wegweiser, kann der Wert combined, multiple oder generic verwendet werden, wenn Semikolonlisten 'Teufelszeug' sind (m.W. sollen Auswerter auch die prinzipiell unterstützen). Wenn ein spezieller Typ nicht ermittelbar ist (weil sich der Wegweiser an jede Gruppe richtet), dann kann guidepost=* auch ganz ausgelassen werden. Der anzunehmende Standardwert dieser Eigenschaft ist dann ebenfalls generic.
Mit den Werten hiking, skiing, cycling, die klar ein und derselben Kategorie zuordenbar sind, ist das guidepost-Tag jedenfalls wesentlich besser besetzt, als das, was da vorher seit 2013 proklamiert wurde. Mein Vorstoß trägt hier eher zu einem gelungenen Datenmodell bei, indem es Werte der gleichen Kategorie einem Schlüssel zuordnet. Es ist auch völliger Humbug, zu behaupten, dass guidepost=* vorher klare und verständliche Informationen wiedergegeben hätte, denn was die Werte destination und overhead anbelangte, wußte mein Vorredner sich nicht so recht einen Reim drauf zu machen. Hier habe ich mit meinem Wissen gerne ausgeholfen und diese Informationen ergänzt.
Was im Forum diskutiert wird ist so eine Sache. Niemand dort kann erwarten, dass das gelesen wird - solange dort niemand in der Lage ist, einen Konsens zu bilden und diesen als halbwegs wasserdichtes Schema im als Hauptanlaufstelle gedachten Wiki zu präsentieren, wird man mit Überschneidungen leben müssen. Se la vi. --Cmuelle8 (talk) 11:38, 25 August 2015 (UTC)
Das ist richtig, dass das, was vorher in guidepost=* drin war, komplett unbrauchbar ist. Will ich gar nicht verteidigen, würde ich ersatzlos löschen. Aber es geht nicht darum, einfach irgendein Tag "besser zu besetzen", weil es halt da ist, sondern es geht immer darum, dass jedes Schema trotzdem sinnvoll und zukunftsfähig sein muss. Und da ist es nicht sonderlich überzeugend, jetzt einfach die Access-Tags ersatzweise dort reinzuschreiben. Zumal ich noch nicht einmal sicher bin, wofür das mit den Access-Tags (in welcher Form auch immer) überhaupt gut sein soll. Was ist der daraus resultierende Mehrwert, außer dass man ein Tag zusätzlich in die Datenbank geschrieben hat? Wenn es beispielsweise darum geht, beim Routing Informationen entsprechend der gerade ausgeübten Aktivität bereitzustellen (beispielsweise beim Skifahren "Folgen Sie der Beschilderung Richtung Abfahrt A!" oder beim Wandern "Nehmen Sie den Weg Richtung Adorf!"), dann würde man bei gemischten Wegweisern auf Probleme stoßen, da es nämlich eine Eigenschaft der einzelnen Richtungsangabe ist, welche gerade passt, und keine Eigenschaft des Wegweisers insgesamt. Dort fehlt also komplett die Perspektive, was man erreichen will und ob die gewählten Mittel dafür passend sind.
Die direction-Keys sind auch dann unpassend, wenn man sie einfach nur als niedrigschwelliges Angebot betrachten will. (Wobei Redundanzen niemals schön sind, da sie erstens untereinander inkonsistent und damit widersprüchlich sein können und Auswertungen verkomplizieren, weil alles mal so oder so erfasst sein kann und meist auch noch irgendwie wild gemischt wird. Für Einsteiger macht es das übrigens auch nicht leichter, wenn nicht ein verbindlicher Weg vorgegeben wird, sondern ständig Alternativmöglichkeiten angeboten werden, bei denen meist auch noch Widersprüche in der Dokumentation auftauchen.) Erstens ist, wie in der Diskussion erwähnt, "direction=*" in Zusammenhang mit Schildern schon anders besetzt. Es sagt nämlich aus, in welche Richtung die Vorderseite des Schilds ausgerichtet ist. Da hat man also schon wieder eine Inkonsistenz bezüglich verschiedener Verwendungsarten, welche ganz und gar nicht einsteigerfreundlich ist (und nur für Einsteiger ist es ja gedacht). Zweitens ist es nicht sinnvoll auswertbar, weil weder ein Format vorgegeben ist und zudem das Problem besteht, dass die direction_xyz-Keys grundsätzlich unbeschränkt sind. Denn wie ebenfalls im Forum erwähnt, könnte ja jemand auf die Idee kommen, dass northwest und north vielleicht beide nicht richtig passen und deshalb direction_northnorthwest genommen wird oder gleich mit Gradzahlen nach dem Motto direction_350 agiert wird. Das ist also unauswertbar. Demzufolge ist also all das, was man dort reinschreibt, lediglich als Notiz zu betrachten. Dann sollte man es aber entsprechend auch als note=* verbuchen, denn etwas anderes ist es nicht. --Kontinentalverschieber (talk) 14:16, 26 August 2015 (UTC)
Das sehe ich anders, sie sind sehr einfach zu verstehen, insbes. in der Human2Human Kommunikation, die OSM nunmal auch ist. Manchmal ist ein Schema, das von Menschen sehr einfach zu durchschauen ist, maschinell sehr schwer auszuwerten, das ist richtig - allerdings ist das nie ein Grund, dass sich der Mensch zwanghaft nach der Maschine richten sollte und statt eines human lesbaren Formats das maschinelle zu bevorzugen ist.
Auch deine Argumentation bzgl. der Redundanzen erweist sich in einem Projekt, dass naturgemäß mehrere Quellen hat, nicht als stichhaltig. Denn redundante Informationen, die untereinander inkonsistent sind, sind genau die Information, dass etwas mit den Daten nicht stimmt und sie überprüft werden sollten. Es gibt hier also einen einwandfreien Mehrwert für Mapper (und für Auswerter, sofern sie gezielt nach Diskrepanzen in redundant vorhandener Info suchen).
direction=* ist ein Schlüssel, den wir bisher nicht besprochen haben. Hier kann ich zwar deine Argumentation nachvollziehen, dass der Schlüsselname den Schlüsseln direction_north=*, direction_south=* ähnlich ist und man das auch unschön finden kann, aber sofern es dokumentiert ist (und das ist es), ist es sauber unterscheidbar. Rein logisch macht es auch wenig Sinn, Richtungsangaben zu Zielen in einer bestimmten Richtung unter direction, dass ja eben keine bestimmte Richtung meint, abzulegen. Hier wäre sign_direction vielleicht schöner gewesen.
Zur Auswertbarkeit: Entgegen deiner Meinung lassen sich direction_xyz-Keys auch dann einwandfrei auswerten, wenn northnorthwest oder Gradzahlen benutzt werden. Jemand der das auswerten will und für den es sich "lohnt", schreibt die Software so und so anhand der Datenlage - und wenn er da northnorthwest oder Gradzahlen als Schlüsselkomponente häufig vorfindet, wird er das mit auswerten. Hält sich die Masse der Mapper an die vier Haupthimmelsrichtungen, schreibt er die Software eben nur für diese. Es macht aber wenig Sinn hier weiter zu spekulieren, das nur als hypothetische Antwort zu deiner hypothetischen Vermutung, es wäre nicht auswertbar.
Zuletzt zur Frage des Mehrwerts. Das ist so ähnlich wie die Frage nach dem Sinn des Lebens. Die beantwortet man sich entweder individuell oder gar nicht - eine allgemeingültige Antwort hat diese Frage nicht. Genausowenig kannst du wissen, für wen diese Information, wenn sie gemappt ist, nützlich ist oder nicht. Mapper sind Datenprovider in the hope this data will be useful to anyone but without any implied warranty to the extent permissible by applicable law.
Es hat hingegen tatsächlich keinen Mehrwert, Daten (oder Datenschemata) unter der Maßgabe "weil ich mir nicht vorstellen kann, dass es irgendjemandem nützt" zu löschen oder zu unterdrücken - bei sovielen "ichs" die an OSM mitarbeiten, gilt dann mit Sicherheit, dass alle Daten aus OSM zu entfernen sind, weil sich für jede Sorte/jedes Tag auch jemand finden lässt, der nicht weiß, wozu das nützlich sein soll. Geh in ein Einkaufshaus: Dort gibt es sicher eine ganze Menge Dinge von denen du dir nicht vorstellen kannst, dass sie irgendjemand auch nur im entferntesten braucht. Dennoch werden sie angeboten und bis auf ein paar Ladenhüter findet sich auch für jedes Ding ein Interessent, der einen Nutzen an den Dingen findest, die du nie und nimmer auch nur näher anschauen würdest. Zurück zu OSM: OSM ist ein Datawarehouse. Nur weil du T-Shirts nicht magst, heißt das nicht, dass man sie entfernen sollte. Willst Du hingegen besondere T-Shirts anbieten, kannst du das - nur das in OSM die Waren aus Informationen bestehen und sie nicht dadurch gemindert werden, dass irgendein Datennutzer sie konsumiert. (Sie sind tatsächlich nur dadurch in Gefahr, dass "sich irgendjemand nicht vorstellen kann, dass ein anderer daran einen Nutzen findet.") Gruß --Cmuelle8 (talk) 17:47, 26 August 2015 (UTC)
Aktuell gibt es 2992 nodes mit direction_xyz-Keys, siehe passenden Overpass Query. Grob drübergeschaut, beschränkt sich die Datenlage hauptsächlich auf die vier Haupthimmelsrichtungen. Gruß --Cmuelle8 (talk) 18:08, 26 August 2015 (UTC)

Komplexe MPs

Hallo Cmuelle8,

zur Beschreibung der komplexen MPs und warum gormo da eine Warnung eingebaut hat, siehe z.B. die Diskussion hier:

http://forum.openstreetmap.org/viewtopic.php?id=52878

Du bist herzlich zum Mitdiskutieren eingeladen. Beste Grüße, --Chrysopras (talk) 07:48, 4 December 2015 (UTC)

Ich lasse mich bzgl. des Wiki-Inhalts nicht auf wiki-ferne Diskussionen ein. Dinge, die dieses Wiki betreffen, sind auch in diesem Wiki zu diskutieren - und nicht umgekehrt. "Frech" ist es, den Einsatz und den Nutzen von MPs nicht wirklich verstanden zu haben und der Community dann einen "Hinweis" überhelfen zu wollen, der auf ein mangelhaftes Verständis der Sache, aber ein großes Ego zurückzugehen scheint. Ich mappe lange genug, um aus meinem Erfahrungsschatz zu wissen/schließen, dass dieser Hinweis in allen seinen Komplikationen mehr schadet als nützt.
Gruß --Cmuelle8 (talk) 07:50, 5 December 2015 (UTC)
Um das noch ein bisschen zu verfeinern: Ich habe großes Verständnis dafür, dass neue Leute in OSM schnell Ergebnisse sehen wollen und aufgrund dessen nach dem "Quick+Dirty" Prinzip Einfachumrisse zeichnen mit denen sie einzig die innenliegende Fläche meinen (können), ohne sich dabei um angrenzende bzw. umliegende Flächen zu kümmern (müssen).
Je mehr Details in der Folge addiert werden, das hat die Vergangenheit oft genug gezeigt, um so schwieriger und missverständlicher werden jene Datenmodelle (sowohl in ihrer Interpretation als auch in ihrer Wartbarkeit), die sich gänzlich auf closed ways verlassen und statt der Flächengrenzen nur Einzelflächen im Sinn haben, d.h. statt die Flächengrenzen und -bezüge untereinander zu berücksichtigen jede Fläche für sich genommen isoliert betrachten.
Wer sich ausreichend mit MPs beschäftigt hat, muss einsehen, dass diese zwar eine komplexere (und anfangs evtl. schwieriger verständliche) Beschreibung ermöglichen, gleichzeitig der Realität des Raumes weit besser gerecht werden, als die legacy-Variante eines closed ways es je könnte. Und wie sich unmittelbar zeigt, ist ein closed way lediglich ein Spezialfall eines MP.
Ja, man kann (immer noch) argumentieren, dass die Unterstützung für MP in den Mainstream-Editoren besser sein könnte, bzw. bessere Assistenten wünschenswert sind, welche die Komplexität bei der menschlichen Handhabung von MPs mindern/verstecken. Das ändert aber die Tatsache nicht, dass MPs die Realität des Raumes adäquater modellieren, als es closed ways tun. Derzeit sind MP der Flächentyp in OSM, closed ways eher eine Krücke, die aus den Anfängen stammt, in denen viele OSMer von "quick+dirty" berauscht waren.
Zusammengefasst: MPs orientieren sich an den Flächengrenzen und modellieren eine Teilung des Raumes in Flächen verschiedenen Typs in der Regel wartbarer und plausibler, als closed ways es je könnten. Nichts desto trotz gibt es keinen MP-Zwang, Mapper können dato selbst entscheiden, welche Form der Flächenmodellierung sie einsetzen. Das Wiki formuliert und erklärt dabei nach Möglichkeit wertungsfrei beide Formen. Vor- und Nachteile können bei Bedarf auch auf einer dedizierten Seite aufgezeigt werden, die sich explizit mit den Unterschieden beschäftigt - ohne dabei die Beschreibungs- und Beispielseiten die speziell einer Form der Modellierung gewidmet sind, zerpflücken zu müssen.
Gruß --Cmuelle8 (talk) 08:31, 5 December 2015 (UTC)
Hallo Cmuelle8,
danke für Deine ausführlichen Einlassungen -- leider wird sie hier keiner lesen (ich habe sie auch gerade nur zufällig gefunden). Die User talk-Seiten werden meist nur für kurze Nachrichten an Nutzer, nicht für Sachdiskussionen genutzt. Der beste Ort, solche Frage ausführlich zu diskutieren, ist das deutsche OSM-Forum. Ich habe Dir einen entsprechenden Hinweis auch auf der Talk-Seite des Wiki-Artikels hinterlassen. Beste Grüße und auf Wiedersehen im Forum, --Chrysopras (talk) 06:05, 9 December 2015 (UTC)
Tut mir leid, aber da muss ich widersprechen, Chrysopras. Wir streben eine Veränderung im Wiki an, die Diskussion dazu gehört ins Wiki. Das ist mein Fehler gewesen, das nicht vorher anzufangen. Ich hab die Diskussion hier jetzt mal von der Artikeldiskussion her verlinkt. Zum Inhalt: für neue Mapper ist es einfach super schwierig, in einem Gebiet das mit aus mehreren Outer gestückelten Multipolygonen gebaut ist, irgendwas zu verändern. Man versteht nicht, wie ein solches Konstrukt aufgebaut ist, jede Änderung ist super schwierig. Spaltet man einen highway=-Weg auf, der als Outer zwischen Wald und Ackerland langläuft (z.B. um neue tracktype=-Attribute zu setzen, die nicht auf dem ganzen Weg gelten), dann muss man mehrere Relationen anfassen. Wenn man da nicht aufpasst, macht man viel kaputt. Aber das ist meine Meinung, und daher könnte ich mich auf deinen Vorschlag Vor- und Nachteile können bei Bedarf auch auf einer dedizierten Seite aufgezeigt werden, die sich explizit mit den Unterschieden beschäftigt - ohne dabei die Beschreibungs- und Beispielseiten die speziell einer Form der Modellierung gewidmet sind, zerpflücken zu müssen. gut einigen. --Gormo (talk) 07:57, 9 December 2015 (UTC)
OK, dann hier. Ich hätte es passender gefunden, auch im Wiki die Artikeldiskussion zu verwenden (da wir ja nicht User:Cmuelle8 diskutieren wollen, sondern den Artikel DE:Multipolygon_Examples ;-), aber wie Ihr möchtet. --Chrysopras (talk) 08:06, 9 December 2015 (UTC)
OSM muss m.E. irgendwann den Sprung nach vorn wagen - das Projekt kann modelltechnisch nicht ewig in den Kinderschuhen verharren, nur weil Kinderschuhe leicht anzuziehen sind. Gormo hat Recht, dass MPs (derzeit) evtl. eine höhere Lernkurve haben als closed ways - aber MPs sind näher an der Realität und den Mappern, die sie verstanden haben und einsetzen ein stärkeres/besseres Ausdrucksmittel, um das zu beschreiben, was in der Realität vorzufinden ist.
  • Das nur grundsätzlich, mir geht es nicht darum neue Nutzer zu verschrecken, im Gegenteil - langfristig bedeutet ein schwaches oder unsauberes Datenmodell schätzungsweise einen herberen Verlust in der Nutzerbasis (oder der Datenkonsumentenbasis). In der Summe ist das aber wie mit Lesen/Schreiben, wurde die Verwendung einmal verinnerlicht, kann man sich damit ausdrücken, egal ob man dabei ab und an Fehler macht, oder nicht.
  • Zudem werden MP recht einfach in einen nativen Flächentyp (sofern er mit irgendeiner der nächsten Versionen der API kommen sollte) konvertierbar sein. Die oft unsauberen oder unverbundenen Grenzlinien benachbarter Flächen bei closed ways werden zwar auch konvertierbar sein, dann aber weiterhin mit Überlappungen/Auslassungen oder Niemandsland dazwischen.
JOSM hat seit geraumer Zeit ein Doppelklick-Feature für Flächen. Möglicherweise ist das noch nicht breit bekannt, aber es macht die Identifikation und den Umgang mit beiden Flächentypen einfacher, als es manche Mapper evtl. derzeit realisieren.
Zum Datenmodell: Die Nutzung von highway=* als outer ist schon ein spezieller Diskussionsgegenstand und spricht nicht gegen MPs per se. Für eine Erklärung dieses Spezifikums unternehme man eine "historische" Exkursion:
"Früher" (auch wenn sich das schräg anhört), als nodes und ways in OSM z.B. noch nicht 64-bittig waren, und z.B. hochauflösende Bilder nicht allenorts verfügbar, war es ein Kompromiss highway=* als outer Mitglieder in MP zu verwenden, denn das spart Speicherplatz im Datenmodell und schont Rechenressourcen. Wege wurden ohnehin auch auf Fotos intuitiv als lineares Feature abgebildet und wahrgenommen. Mit mehr Rechenkapazität und besseren Luftbildern änderte sich hingegen die Wahrnehmung des/der Mapper. Der Wunsch nach mehr Detailtreue entstand, neue Tags und Modelle (area:highway=*) wurden etwa um das Jahr 2011 vorgeschlagen, um diese Detailtreue in hohen Zoomstufen abzubilden.
Ich denke es ist klar und intuitiv, dass wenn eine Flächenrepräsentation eines highway=*s gezeichnet wurde, die idealisierte Mittellinie (das lineare, ein-dimensionale highway=*-Feature) nicht mehr als outer-Mitglied eines MP herhalten muss.
Aber es ist auch klar, dass in Gebieten mit wenig Ressourcen und/oder schlechten Luftbildern, es weiterhin eine Möglichkeit (neben anderen) bleibt, Gebiete grob auf diese Weise zu erstellen. Natürlich ist es zu einem späteren Zeitpunkt wünschenswert, auch dort die Detailrepräsentation zu ergänzen und den linearen highway wieder von seiner Mitgliedschaft in solchen MP zu befreien.
Anfänger in OSM, die so etwas nicht verstehen, haben es schwerer dort etwas beizutragen. Das ist richtig. Aber das gilt auch für einfachere Dinge. Z.B. wurden und werden oft (und scheinbar rücksichtslos) route-Relationen zerstört - aus exakt demselben Grund. Man kann Mapper nun ignorant nennen, wenn sie diese Relationen nicht berichtigen, nachdem die Basisgeometrie verändert wurde oder man akzeptiert einfach den Fakt, dass OSM ein lebendiges Projekt ist, bei dem
  • a) auch mal etwas kaputt gehen kann und darf und
  • b) Menschen schrittweise dazu kommen, dazu lernen oder auch das Projekt verlassen/pausieren
"Es ist noch kein Meister vom Himmel gefallen", heißt es. Wenn das Know-How fehlt, eignet man es sich erst an und ändert dann - nicht umgekehrt. Wir lassen auch (eigentlich!) niemanden ans Steuer bevor nicht eine Fahrschule o.ä. durchlaufen wurde. Selbst Schießwütige müssen erst ihr Handwerkszeug "lernen", bevor sie zu Felde ziehen, ob in Polizei, Armee, Schützenverein oder sonstwo. Auch wenn der Einstiegspunkt in OSM niedrig ist, ein wenig Know-How muss man sich eben doch aneignen, wenn man Spaß haben will (eine der goldenen Regeln von OSM).
Gruß --Cmuelle8 (talk) 20:51, 9 December 2015 (UTC)
Wer sich mit dem Erstellen einer dedizierten Seite beschäftigen will, welche die Vor- und Nachteile beim Flächenmappen durch die ein oder andere Methode beleuchtet, ist m.E. gut beraten, repräsentative Beispiele der Realität auszuwählen, an denen dann alle Möglichkeiten einer Modellbildung durchexerziert werden. Warnung vorab: Mit Screenshots der Arbeitsschritte und Resultate bedeutet das eine ganze Menge Aufwand, der insbesondere dann nicht gerechtfertigt scheint, wenn man schätzt, dass sich die Prämissen ändern (z.B. durch die Einführung eines Flächentyps in der OSM-API). Weiterhin möchte ich vor philosophischen Implikationen warnen, denn die Unterteilung des Raumes in Grenzflächen ist nach "unten" hin sehr weit offen und es mag anmaßend sein, verschiedene Sichtweisen bei dieser Unterteilung als richtig oder falsch zu sondieren.
→ Es sei hier bsp.-weise auf die Frage danach verwiesen, was ein Wohngebiet ist, ob es sich scharf oder unscharf abgrenzt und wenn ja, woran (welche micro-gemappten Teilflächen gehören dazu, welche nicht mehr) und lässt sich das wie auch immer gefundene/definierte Modell dann noch mit dem allg. Sprachgebrauch vereinbaren (was wichtig ist, wenn das Mappen intuitiv bleiben soll). Z.B. könnte OSM für die Definition dessen, was ein Wohngebiet in OSM genau sein soll, der Definition der Landesämter folgen (bei denen die Anwohnerstraßen z.B. nicht zu den Wohngebieten zählen), diese Definition wiederum ist aber meiner Auffassung nach nicht im allg. Sprachgebrauch wiederzufinden, denn da zählen die Wohnstraßen sehr wohl zu den Wohngebieten.
→ Und wo genau liegt der Unterschied zwischen Wohn- und Siedlungsgebiet (landuse=residential vs place=village|suburb|quarter)? Ist eine scharfe Definition möglich mit der Mapper Gleiches gleich mappen? Wie intuitiv ist wieder die für OSM hinterlegte Definition, wenn der allg. Sprachgebrauch als Referenz dient? Ist es anfänger-freundlich, wenn man sich durch 'zig Seiten Foren, Mailinglisten und Hilfeseiten ackern muss, bevor eine brauchbare Vorstellung bestehen kann, was in OSM unter Wohn- bzw. Siedlungsgebiet verstanden wird?
→ Ich möchte damit zu Bedenken geben, dass man sich bei einer vergleichenden Darstellung bewusst werden sollte, dass die "Dinge" fließen. Diese vergleichende Darstellung muss folglich aufpassen, keinen Zirkelschluss auf sich selbst zu liefern. Denn dann wäre ihr Anspruch bereits in Teilen die Definition des oder der Vergleichsgegenstandes/ände. Zudem ist ein objektiver Standpunkt schwierig, denn je nach Kenntnisstand werden Aufwand und Komplexität bei der Anwendung beider Verfahren unterschiedlich bewertet, der Vergleich damit evtl. notwendigerweise subjektiv gefärbt.
→ Viele Modellierungsfragen lassen sich häufig auch dadurch klären, bzw. vermeiden, indem in der Datenbasis danach gesucht wird, wie andere Mapper mit einem Problem umgegangen sind. Lernen durch Kopieren. Das birgt aber auch die Gefahr (die Chance?), dass am Ende regionale Lösungen entstehen/bestehen, die Ähnliches oder gar das Gleiche leicht unterschiedlich darstellen. Das ist in einem einheitlichen Datenmodell zwar nicht wünschenswert, kopiert aber in gewissen Grenzen Prinzipien der Evolution, die sich in der Vergangenheit als robust erwiesen haben (vgl. Monokultur-Resistenzen zu biolog. Diversität).
Gruß und viel Spaß beim mappen. --Cmuelle8 (talk) 21:22, 9 December 2015 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=User_talk:Cmuelle8/Archive&oldid=1260668"