Unterscheidung für mich: Die Detailtiefe und der Anspruch.
Eine Karte bleibt für mich eine Karte, auch wenn sie in Datenbanksprache vorliegt. Sie hat den Zweck, eine Übersicht zu erstellen.
Eine Datenbank oder Wissensammlung (hier fällt mir leider kein besseres Wort ein) hat in dem Sinne in dem ich das benutze, die Idee, möglichst alle Daten zusammenstellen, die es überhaupt gibt.
Also einmal den Anspruch Informationen der Realitätswahrnehmung hinzuzufügen und einmal die Anspruch die Realitätswahrnehmung zu abstrahieren.
Beide Ansätze sind natürlich berechtigt, aber nicht kompatibel. Von historischen Ausgrabungen werden ja oft “Karten” im Masstab 5:1 (also fünfmal grösser als das Objekt) angelegt…
Wenn jemand eine bessere Abgrenzung und Wort findet, übernehme ich die gerne.
ist die usuability. Je mehr solche Dinge es gibt, desto schwieriger wird es mit den Daten zu arbeiten. Wenn man diesen Konflikt ohne Informatikstudium auflösen kann, stimme ich Dir zu. Und wenn diese Detailverliebtheit nur Ergänzungen sind, mit denen der Haupttag noch funktioniert. Wenn das Laternenmastendetailmapping dazu führt, dass das Tag “lit=yes” sich nicht mehr auswerten lässt, finde ich das einen Nachteil.
Wie seawolf sagt gibt es ja Bereiche, wo dieses Tagging völlig unproblematisch ist - beispielsweise Hydranten etc. Wenn sich allerdings nur durch komplizierte Abfragen erahnen lässt, ob ich da jetzt Trinkwasser zapfen kann oder nicht (weil ich aus 150 Hydranten die eine spezielle Trinkwasserstation filtern muss) nervt es. Wenn ich - nach 4 Jahren aktivem mapping - immer noch daran scheitere, irgendwie mitzuteilen “da auf der Strasse gibt es eine Buslinie” gibt es eindeutig einen Punkt, wo die Details dazu führen, dass man die Abstraktion nicht mehr eintragen kann.
Die manpower und die Integrationsfähigkeit des Projektes. Du gehörst ja zu den Menschen, die durch Ihre Tutorials auch daran arbeiten, die Schwellen zu senken. Je mehr Möglichkeiten eine Lösung hat, desto komplexer wird es, sie zu bedienen. Und für mich ist es längst so, dass eine Integration aus beiden Richtungen erfolgen muss.
— edit: Nimm einen Kreisverkehr oder das Spurmapping auf Strassen und den Versuch eine Buslinie einzutragen. Hast Du eine Strasse und einen Kreisel sind das zwei Arbeitsschritte. Fängt jemand an, den Kreisverkehr in Segente aufzuteilen, musst Du auf einmal die Segmente aufteilen, für hin- und rückweg andere Routen für die Buslinie finden und hast mindestens die 20 fache Menge an Arbeit - Arbeit die nach meiner Meinung wo anders besser ist. Und lässt Du das was Du nicht sinnvoll findest weg (wozu um alles in der Welt muss ich Wissen, dass ein Bus der abbiegt, die Abbiegespur nutzt?), geht auf einmal das Ganze nicht mehr.
Im Grunde sind das eher Problemchen, wenn man die Größe des Projekts betrachtet. Letztlich ist es egal ob path oder cycleway, solange man nicht dauernd neue Sachen erfindet, die dann nur bei uns gültig sind und die Auswerter ignorieren.
Was ich aber auch schade finde ist, dass hier Diskussionen so selten wirklich in der Wiki Auswirkungen haben. Da sollten wir konsequenter sein, selbst ein Dissens kann man dort eintragen, damit die Diskussion nicht jedes Jahr von neuem los geht.
Aber hoffentlich noch mit einer sinnvollen Genauigkeit und nicht so. Wenn ich das sehe, geht mir nämlich die Hutschnur hoch - 708 Nodes auf reichlich 1,5 km Trampelpfadlänge. Und das ist in dem Gebiet auf nahezu jedem Weg so.
Wer so etwas macht, sollte sich erst einmal Gedanken um die Genauigkeit seiner Positionsdatenquelle machen! Weder GPS noch ein Abzeichnen vom Luftbild geben das überhaupt sinnvoll her. Ganz davon abgesehen, dass man damit nur dafür sorgt, dass diese Daten kaum noch nutzbar sind, weil Rendern und Routen dann sehr viel mehr Zeit braucht und zudem die notwendigen Dateigrößen aufgebläht werden.
Für mich ein supergutes Beispiel von völlig unnötiger Komplexität. Gib dem Editor eine Standartdichte für Nods vor und niemand muss sich darum kümmern, ob seine Pfade oder Wege genug vereinfacht sind.
Sowas entsteht aber meine Meinung nach tatsächlich aus einem GPS aufgezeichnetem Track. Bist Du mit Kindern, Hund oder sonstwas unterwegs und nutzt Zeitabstände für die Aufzeichnung, kommt oft sowas bei raus.
Ich würde zustimmen, dass die Diskussionen zu oft zu wenig produktiv im Sinne von greifbaren Ergebnissen (im Wiki) sind.
Andererseits bin ich nicht dafür, das Wiki zu einer Plattform für Alternativdarstellungen zu machen. Das Wiki dient dazu, dass sich insbesondere auch Anfänger einarbeiten können. Denen ist aber nicht geholfen, wenn es heißt, dass man es so oder auch anders machen kann. Denn ohne Erfahrung in dem jeweiligen Bereich überblickt man die sich daraus ergebenden Konsequenzen nicht und dann lässt man es lieber ganz bleiben und wartet ab, ob sich dort in Zukunft eine Richtung herauskristallisiert. Es braucht also verbindliche Regeln und nicht Optionsmodelle.
Nebenbei sorgen Alternativen nur dafür, dass Daten letztlich nicht verwendet werden. Denn das bedeutet auch auf der Auswertungsseite, dass man erst einmal abwartet, was sich wohl durchsetzen wird. Denn kaum jemand hat Lust, auch noch verschiedene Schemas für einen neu aufzunehmenden Sachverhalt zu implementieren und zu unterstützen.
OSM ist nun einmal eine Datenbank. Und da kann man nicht sagen: Jeder, wie er mag. Sondern da braucht es Eindeutigkeit und Verbindlichkeit, weil man sonst mit der Datenbank nichts anfangen kann.
Kann mich seawolff großteils leider nur anschließen.
Nach der ersten Euphorie über das Projekt macht sich schnell Ernüchterung breit.
Ich glaub ich hab noch nie eine Bushaltestelle komplett erfasst. Wozu auch?
Selbst Adressen brauchbar zu erfassen, hat mehrere Evolutionsstufen gebraucht.
Beim letzten Filtern der Kartendaten für einen Kunden habe ich 60% der Daten in OSM weggeworfen. Unbrauchbar auszuwerten oder zu kompliziert. Frag mich wie vielen Nutzern es da draußen auch so geht?
Kurz gesagt:
Ein verbindlicher Gold-Standard würde helfen. Alles andere bleibt optional oder kommt weg.
Ohne wiki-Eintrag kein Tag! Eigene Tags → Eigene Datenbank.
Details sind nett, aber meistens unnötig, Referenzen sind besser.
Verbindliche Presets für alle Editoren für Anfänger und Warnungen bei nicht gebräuchlichen Tags würden schon viel helfen.
Irgendjemand oder eine offizielle Gruppe (ähnlich: OSM Boundaries, Railway Map, Emergency Map etc) sollte mal die Datenbank vereinheitlichen und bei Problemen zeitnah darauf hinweisen. Einfach nur auf gut Glück Fehler manuell im lokalen Bereich zu finden funktioniert nicht.
Einfacher und wenigstens ein paar verbindliche Regeln wäre besser.
Habe gerade festgestellt, daß ich meinen ersten Changeset am 11.11.11 um kurz vor 11 Uhr abends getätigt habe - wenn das mal kein Fastnachtsscherz ist!
Ich habe inzwischen meine Nische in OSM gefunden mit dem Thema Bergbau und mit www.historic.place.
Über das Datenmodell könnte ich mich aufregen, habe ich aber aufgegeben.
Taggingdiskussionen sind meist frustrierend und führen nur selten zu einer Verbesserung.
Sowohl im Forum wie auch auf der Mailingliste sind immer die üblichen Verdächtigen aktiv. Diese ca. 20-30 Köpfe vertreten sicher nicht repräsentativ die Meinung der OSM-Community, einige tun aber als ob.
Der Ton im Forum hat sich verschlechtert seit ich angefangen habe. Daher habe ich mich daraus weitgehend zurückgezogen. Andere Mitstreiter haben sich daran noch mehr Frust geholt und ganz aus OSM zurückgezogen, was ich in Einzelfällen extrem bedauere.
Ich stelle aber auch immer wieder fest, daß es noch Enthusiasten gibt, die trotz aller Widrigkeiten, die durch die Architektur des Projekts und die menschliche Eitelkeit bedingt sind, sich nicht beirren lassen und positiv zum Projekt beitragen. Diesen sage ich: Hut ab und weiter so!
Ich bin mir ziemlich sicher, dass das in dem Gebiet in der Regel nicht der Fall war, sondern dass das mit Luftbildern von zu Hause aus gemacht wurde. Denn nicht nur Wege sondern auch kleinste unzugängliche Bachläufe (die definitiv nicht abgeschritten werden können, weil das Gelände zu steil ist) waren dort teils mit ähnlichem Detailgrad gemappt. Zudem stimmte das Wegetagging nicht ansatzweise mit den Bedingungen vor Ort überein, sondern es wurden einfach Standardtags gesetzt (sac_scale=mountain_hiking, selbst wenn es ausgesetzte Kletterpassagen auf dem Weg gibt, die mindestens mit alpine_hiking anzusetzen sind - derartige Fehlinformationen sind darüber hinaus ziemlich gefährlich).
Mir geht das so. Ich werf die anderen 40% weg und bin glücklich mit “Deinen” 60%. UserXY wirft eine andere Teilmenge von Deinen 60 und meinen 40 weg usw.
Zu deutsch: der Frust ist eingebildet, Deine Daten sind da, meine sind da, die von UserXY sind da.
Die Lösungsvorschläge* hier diesbezüglich, auch wenn sie nur teilweise zwischen den Zeilen stehen, machen genau das Gegenteil von dem was sie sollen: DIE machen Frust.
Abstrahiert und übertrieben: hier wird besprochen, Tagging für Hundekotbeutelspender abzuschaffen, ich brauch die nicht, für mich ist der Gedankengang trotzdem inakzeptabel. Ich werf die weg und alles ist prima. Genau DAS macht (u.A.) OSM für mich aus.
+1 Die Vorteile, dass jeder das ‘rausziehen’ kann was ER braucht überwiegen meiner Meinung nach.
Konkretes Beispiel:
Kürzlich war eine Freundin von mir in einer ihr unbekannten eher ländlichen Gegend bei einer Wohnungsbesichtigung.
Auf dem Rückweg zum Bahnhof an diesem heißen Sommertag brauchte sie DRINGEND aus div. gesundheitlichen Gründen eine Sitzgelegenheit, konnte aber keine finden. Was meinst du wie glücklich sie war als ich sie telefonisch (OSM sei Dank) zur nächsten Parkbank (mit Rückenlehne) lotsen konnte?
Ein bisschen später hätten wir einen Rettungswagen schicken müssen…
Gleichzeitig bin ich voll bei dir, dass sicherlich etliche (va sogenannte ‘micromapping-’) Daten unnötig oder veraltet, bzw - was viel schlimmer ist - uneinheitlich oder widersprüchlich sind; dadurch nützen sie niemandem etwas und bringen Nachteile. Fakt ist: Keiner weiss aber was der andere braucht.
Ich habe stark das Gefühl, das viele Micromapper Dinge mappen, die sie selbst garnicht brauchen, sondern einfach nur weil sie noch nicht in OSM eingetragen wurden (und womöglich sonst nichts finden?!), mit dem Argument: VIELLEICHT braucht das ja jemand. Daraus resultierend liest man des öfteren über Themen wie schwierige Auswertung, Vor- und Nachteile von tags usw - ohne aber konkret bekanntzumachen, was eigentlich gebraucht oder ausgewertet wird.
Ich bin überzeugt: gäbe es in irgendeiner Art eine Übersicht aller tags die auch tatsächlich von jemandem* ausgewertet werden, gäbe es auch weniger Micromapping mit unnützen ungenutzen Daten. btw wäre ein solcher ‘Status’ eines Tags (gekennzeichnet zB im Wiki) bestimmt für Einsteiger einfacher die ‘richtigen’ Tags zu finden und die Anzahl verschiedener Tags für die gleiche Sache zu minimieren… (Siehe zB die Checkdate-Thematik…)
*klar kann das potentiell jeder Mensch auf dieser Erde sein… aber von den 1. typischerweise aktiven und regelmäßigen Auswertern und 2. Personen, denen ein bestimmtes Tag wirklich wichtig ist dürften sicherlich repräsentativ nahezu 100% aller ausgewerteter Tags abgedeckt werden.
Ich finde auch, dass es in OSM zu viel Wildwuchs gibt. Bestimmte Dinge sollten einfach weltweit einheitlich getaggt werden. Das von dir angesprochene Problem wie z.B. Schulen oder Universitäten zu mappen sind ist eines davon. Ich weiß bis heute nicht, was da die Norm ist. Ich finde es auch nicht gut, dass manche Regionen vom Mapping-Stil her so voneinander abweichen. Speziell in Osteuropa habe ich ein paar Städte gesehen, in denen z.b. exzessiv “Wälder” in Wohngebieten/privaten Grundstücken eingezeichnet waren. Da hatte ich echt das Gefühl das ist nur eingezeichnet weil’s nett aussieht.
Ganz schlimm finde ich auch die Art und Weise wie Namen oft getaggt werden, speziell in mehrsprachigen Ländern oder dort, wo nicht im lateinischen Alphabet geschrieben wird. In Südkorea steht z.B. teilweise nur der koreanische Name im name-Tag, teilweise aber auch mit lateinischer Transkription. Zypern ist aus unerfindlichen Gründen nur auf Englisch gemappt, Griechische Straßennamen sind meistens nicht Mal in der Datenbank.
Geht mir als Gelegenheitsmapper-Rookie ebenso. Relationen sind mir immer noch ein Graus, Public-Transport bloss die Finger weg…
Gerade den letzten Punkt sehe ich als enorm wichtig an. Wenn JOSM es hinbekommen hat mich per Vorlagendialog eine Fußgängerbedarfsampel mit crossing=traffic_signals, highway=crossing eintragen zu lassen und ich dann später durch QS Tools darauf hingewiesen werde, da soll was falsch sein und angemeckert wird, dass es lauten müsste button_operated=yes, crossing=traffic_signals, highway=traffic_signals ist was ganz doof gelaufen. Ich möchte mithelfen die Karte (Datenbank) zu verbessern. Kommt da so was raus und ich muss wochenlang hinter meinen eigenen Anfängerfehlern herzuräumen, führt das zu einer Verschlimmbesserung der Daten. Ich will ne Bedarfsampel eintragen. Nebenbei beim Radfahren Daten sammeln die dazu führen dass Wegebeschaffenheiten, Steigungen, lebensgefährliche Drängelgitter und Schranken mitten im dunklen Wald verfeinert werden, damit meine Fahrrad-App ne tolle Route planen und berücksichtigen kann, dass ich einen Kinderanhänger dabei habe und keine Treppen klettern und frühzeitig vor lebensgefährlichen Drängelgittern einen Meter hinter einer Kurve warnen kann. Oder die App weiß, dass der Weg nicht für die Trekkingräder, sondern nur für die MTB’s geignet ist. Mithelfen Daten zu erfassen, die Tante Autonavi braucht um mir zu sagen "In 100 Metern den zweiten Fahrstreifen von links nutzen um in 500 Metern links auf die Dingens-Allee in den dritten Fahrstreifen von rechts abzubiegen (1. Linkabbiegerfahrstreifen führt in den Bauhof, wenn Sie auch in diese beliebte Falle tappen müssen Sie wegen der baulichen Fahrbahntrennung 9 Kilometer Umweg bei 40 Minuten zusätzlichem Zeitaufwand in Kauf nehmen, weil der Verkehr hier gerade mehr steht als rollt…)
Und nicht x-tausend Wiki-Seiten auswendig lernen.
Die Mitarbeit an OSM ist für mich keine Langeweile. Sie eine Mischung aus “was für’s Gemeinwohl tun” und “der Gemeinschaft zurück geben” weil andere schon “gegeben haben” und viel erfasst haben, was es mir ermöglicht mit einer gescheiten Streckenplanung ganz wunderbare Zeit mit meiner Familie da draußen auf dem Rad zu verbringen.
Und je mehr Zeit ich damit verbringen muss meine eigenen Fehler zu bereinigen, die mir das Prüfungstool des Editors hätte ebenso vor dem Upload anzeigen können, wo externe Tools das später können, desto weniger Zeit bleibt die unterwegs erfassten Daten zu verfeinern.
Ich denke (und das scheint mir auch eine Folgerung von seawolff zu sein, siehe seine Aussage zu Haralds Umfragetool), ein Hauptproblem ist die fehlende Autorität. Einerseits ist es eine gute Sache, dass neue Tags eben erfunden und ausprobiert werden können und man nicht mit den Entscheidungen von anno dazumal leben muss, wenn sie längst nicht mehr geeignet sind. Andererseits gibt es aber dadurch leider auch keine vernünftige Möglichkeit, solch veraltetes Tagging loszuwerden, weil es natürlich immer Anhänger gibt, die das für das Beste halten. Siehe neulich die nach Jahren erfolgte Umstellung von landuse=farm und den Widerstand dagegen. Und auch die gab es letztlich ja dann nur, weil es eben doch eine Autorität gab, die sich durchgesetzt hat, in diesem Fall die OSM-Carto-Leute. Die Frage ist bloß: Wie soll man diese Problematik auflösen? Vielleicht wäre es möglich, dass man zumindest zu ein paar großen Fragen regelmäßige Mitgliederbefragungen macht - richtig öffentlich, nicht irgendwo im Wiki wie bei Proposals. Sondern z.B. beim Einloggen auf der OSM-Website die Umfrage präsentieren und die Ergebnisse sammeln. Evtl. alle registrierten Mitglieder per Mail darauf hinweisen. Im Prinzip das selbe Verfahren wie bei der Lizenzänderung. Und dann, wenn ein Ergebnis da ist (und das ausreichend eindeutig ausfällt), eben (teil-)automatisiert umtaggen, ähnlich wie letztens bei landuse=farm, aber dann eben mit dem Argument des Umfrageergebnisses im Rücken. Solche Ergebnisse würden dann natürlich auch Auswerter, vor allem die großen wie z.B. eben der Carto-Stil oder die JOSM und (hoffentlich) ID Leute kurzfristig umsetzen - so wäre man dann auch nicht mehr von einer willkürlichen Autorität (wie ‘im Carto-Stil wird es jetzt nicht mehr gerendert’) abhängig.
Mir war aber klar, dass ich das würde rechtfertigen müssen. Also: aus (1) mache ich (2) und finde angesichts der gesammelten GPS-Spuren in (3) diese Genauigkeit durchaus angemessen.
Auf einem geraden Stück Straße wirst du bei mir genau zwei Nodes finden, einen vorn und einen hinten. Trifft auf die meisten Grade-4/5-Feldwege zu, die einfach zwischen die Ackerflächen gefahren sind. Wenn ich da eine Kruckellinie sehe, offenbar direkt vom GPX abgekupfert, dann geht es meinem Hut ebenso wie deinem. Da habe ich auch kein Problem damit, Nodes zu löschen, weil es IMHO das Modell der Realität, das wir anstreben, verbessert.
+1 Ich sehe das genau so. Ich finde es sehr anmaßend zu sagen: “Ich brauche das nicht, also ist es nutzlos”. Niemand ist das Maß aller Dinge und niemand kann beurteilen, was für jeden in jeder Situation nützlich ist. Ich habe z.B. letztes Jahr einen Fossgis-Vortrag gesehen wo auch jemand der Meinung war, dass mappen vom Bänken und Mülleimern sei schlecht, weil nicht langlebig. nicht wartbar und ohne großen Nutzen. Kurze Zeit später schob ich einen Kinderwagen durch einen weitläufigen Park und war verzweifelt auf der Suche nach einer Rast- und Wickelmöglichkeit.
Es hat alles zwei Seiten. Auf der einen Seite kann ich dem Buttom-up Ansatz von OSM durchaus etwas abgewinnen. Anders ist z.B. der Top-down Ansatz der Wikipedia, bei der z.B. nichts relevant ist, wenn es nicht in die Relevanzkriterien erfüllt. Das schafft klare Verhältnisse, aber auch ein Klima der Bürokratie und Aggressivität in der man erst zig Regeln lernen muss, bevor man irgendetwas beitragen kann und oft gemaßregelt wird. Das schreckt schnell ab.
In OSM kann man erst mal vor sich hin schaffen und solange es nicht grob falsch ist kommt man sich erst mal nicht ins Gehege. Jeder kann mappen was er für wichtig hält und sich erst mal mit einfachen Werkzeugen grob behelfen, bevor man mehr Wissen hat und es dann Detaillierter macht oder es von jemand anderes ergänzt wird. Ich finde es auch bis zu einem gewissen Grad ok, dass mehrere Taggingschemata zumindest zeitweise parallel existieren. So kann man erst mal ausprobieren was sich bewährt und was nicht. Eventuell setzt sich das bessere durch, manchmal sind auch für unterschiedliche Fälle unterschiedliche Lösungen Vorteilhaft.
Die andere Seite kann ich auch gut verstehen. Ich würde mir auch oft mehr Einheitlichkeit und Verbindlichkeit wüschen. Es gibt nicht schlimmeres als wenn auf mehreren Wiki-Seiten unterschiedliche Dinge stehen und man nach ewiger Recherche wie etwas gemappt wird so hilflos und unwissend ist wie vorher. Als Softwareentwickler finde ich es auch problematisch, dass die Daten schwer auszuwerten sind weil sie uneinheitlich und unstrukturiert sind. Hierbei denke ich aber auch, dass sich das Datenformat der OSM vielleicht nicht für alles eignet, Stichwort “universelle Geodatenbank”. Alle Datensätze in OSM sind quasi Freitext und im Gegensatz z.B. zu Wikidaata ohne fest eingebaute Datentypen und Validation. Das macht es recht flexibel und leicht erweiterbar auf der einen Seite, aber für strukturierte Abfragen schlecht geeignet. Eventuell erreicht man ja durch die Verknüpfung beider Datenbanken das beste beider Ansätze.
Manchmal ist die Genauigkeit auch reine Konvention. Oft weis man, z.B. dass ein Kreisverkehr oder Gebäude in der Realität kreisrund ist und auch Autobahnauffahrten folgen meist mathematisch exakt beschreibbaren Kurvenverläufen. Das kann man mit Geraden nur annähern, wobei die Genauigkeit nur durch die Zahl der Nodes begrenzt wird.
Notiz am Rande: Genau die haben mir schon mal weitergeholfen, als ich mit dem Hund in einer fremden Stadt spazierte und er zu ungewöhnlicher Tageszeit nochmal Stuhldrang verspürte. Meist habe ich Beutel dabei, da hab ich nicht mehr damit gerechnet. Osmand konnte mir aber sagen, dass zwei Ecken weiter ein Hukospender hing, und ruckzuck war der Haufen weg, und der halb vertrocknete daneben gleich mit, womit auch die gute Tat für den Tag abgehakt war.
Niemals etwas für unnütz halten, nur weil man selbst keinen Nutzen draus ziehen kann.
