9 Jahre OSM - eine persönliche Bilanz

Guten Morgen,

bei deinen Gedanken kann ich mich weitgehend neben dich stellen.

Bei einem "klassischen" Fazit stellen sich meines Erachtens immer drei Fragen:
- Woher kommen wir?
- Wo stehen wir heute?
- Und: Wohin wollen wir?

Die letzte Frage ist eigentlich die Wichtigste ... bleibt (bislang) aber leider unbearbeitet. Von daher fände ich es gut, wenn wir diesen Post für die Erarbeitung möglicher Zukunftsperspektiven nutzen würden.

Gruß Klaus

Was mir so spontan einfällt ...
- Es fehlt ein konkreter Tagging-Gold-Standard. Basis müßten dabei die Vorschläge der Community sein. Die finale Festlegung und Dokumentation müßte aber von einer "offiziellen" OSM-Arbeitsgruppe erfolgen.
- Das Tagging sollte (gegebenenfalls automatisiert) vereinheitlicht werden. Basis wäre der Gold-Standard und mehrheitlicher Konsens in der Community. Durchzuführen wäre das wiederum durch eine Arbeitsgruppe.
- Beschränkung der DB-Inhalte. Hier sollte man überlegen, ob man wirklich jedes Objekt in der Datenbank haben möchte. Insgesamt besteht ein gewisse Gefahr, daß man in der Datenflut ertrinkt. Weniger ist oft mehr.
- In der Realität kommen "Linien" eher selten vor. Dort wo möglich sollte man z.B. Straßen in Flächen umtaggen. Insgesamt wäre das eine Entwicklung hin zu einer Art "Grundkarte".

Moinsen,

@seawolf, mir geht es sehr ähnlich wie Dir.
Ich bin inzwischen auch Urlaubs- und Gelegenheitsmapper und Forengelegenheitsleser/-kommentierer.

@tox-rox
Ein Gold-Standard konnte und wird sich nach meinen Beobachtungen durch die vielen Meinungen und fehlenden verbindlichen Beschlüsse (Korrekturen der Wiki Artikel, Anpassung der Editoren - wie seawolf schon anmerkte) nicht durchsetzten. Ich habe hier die Hoffnung aufgegeben.

Weniger ist mehr, sehe ich genauso, aber es gibt auch die "Grashalmfraktion" 🙂 .

Linie oder Fläche das ist hier die Frage :-)
Als Geodät sehe ich die Karte/Datenbank immer nur als abstraktes Modell der Wirklichkeit. Und bei den unterschiedlich ausgeprägten Fähigkeiten der Mitmapper abstrakt zu denken, werden wir uns immer an dieser Frage reiben müssen.
Vielleicht könnten die Renderer den "Width" Tag auswerten und über Verdrängungsoperationen Darstellungen generieren.

toc-rox wrote:

- In der Realität kommen "Linien" eher selten vor. Dort wo möglich sollte man z.B. Straßen in Flächen umtaggen.

"Umtaggen" bestimmt nicht! Sicher mag es den Malkünstlern da in den Fingern jucken, aber auswertungstechnisch sind Flächen eine Katastrophe, insbesondere für Router. Wie bescheiden das funktioniert, sieht man an Fußgängerzonen. Üblicherweise werden dort dann die wichtigsten Wegbeziehungen zusätzlich noch als Pfad darübergelegt, um sinnvolles Routing zu ermöglichen.

Passt übrigens auch nicht dazu, dass du dich im vorherigen Punkt für eine Beschränkung der Datenbankinhalte aussprichst. Eine Karte ist nun einmal eine Abstraktion. Durch dieses große bunte Gebilde auf der Homepage, auf dem Malerfolge sofort sichtbar werden, scheinen das aber eine ganze Anzahl von Leuten mit einem riesigen Mandala zu verwechseln und deshalb wird ständig über irgendwelche geometrischen Verfeinerungen geredet, aber wenig an sinnvolle Auswertbarkeit und Verknüpfbarkeit gedacht.

Lieber Seawolff,
mir geht es genauso. Da ich aber das Mappen nicht aufgeben wollte, habe ich mich auf Mapping in Nepal konzentriert. Insgesamt fehlt mir in Deutschland ein Verein bei dem solche Themen verbindlich diskutiert werden könnten. Sonst bleiben wir bei dem Status Quo.
Viele Grüße,
Marek

Kontinentalverschieber wrote:

"Umtaggen" bestimmt nicht! Sicher mag es den Malkünstlern da in den Fingern jucken, aber auswertungstechnisch sind Flächen eine Katastrophe, insbesondere für Router. Wie bescheiden das funktioniert, sieht man an Fußgängerzonen. Üblicherweise werden dort dann die wichtigsten Wegbeziehungen zusätzlich noch als Pfad darübergelegt, um sinnvolles Routing zu ermöglichen.

+1. Wir können gern Verkehrsflächen zusätzlich taggen, aber die grundsätzliche Abstraktion des Straßennetzes in Linienform halte ich für unverzichtbar – schon weil wir für etliche Anwendungen (oneway=*, incline=*, direction=* etcetera sowie :forward und :backward) den Richtungsbezug brauchen, der bei reinem Flächenmapping verlorenginge. Wie man Abbiegebeschränkungen bei Flächenmapping definieren will, weiß ich auch gerade nicht.

area:highway=* kann highway=* ergänzen, aber kaum ersetzen, solange wir Routinganwendungen unterstützen und nicht nur ein vektorisiertes Luftbild haben wollen.

--ks

Hallo seawolf!
Es ist super schön, dass Du als "Urahn" hier einmal Themen einbringst und die Offenheit hast, auch Deien persönlichen Eindrücke einzubringen. Bei allem was OSM ist, fehlt mir der soziale Aspekt doch manchmal sehr.

Ich bin jetzt nicht so lange dabei wie Du, aber ich finde mich in vielen Dingen von Dir wieder. Ich würde den Prozess so beschreiben:

Openstreetmap entwickelt sich von einer Karte zu einer Geodatenbank - und dabei möchten viele - unter anderem ich - nicht mitmachen

Ich bin mittlerweile auch oft genervt. Für mich ist Openstreetmap eine kartograpfisches Werk - das nun halt mal technisch in einer Datenbank umgesetzt wird. Eine Karte im Masstab 1:1 macht keinen Sinn - eine Karte erfordert Generalisierungen undVereinfachung und im gewissen Masse Konsistens. Ich möchte aus den 50.000 einzelnen Informationen eine machen um den Überblick zu gewinnen.

Im Gegensatz dazu scheint in vielen Taggingdiskussionen das Modell einer Geodatenbank vorzuherrschen - und ein grosses Bestreben - das nicht offen diskutiert wird - , die Realität imMasstab 1:2 abzubilden. Also Objekten, die man in der Natur findet, möglichst noch weitere Ebenen, Referensen etc hinzuzufügen.

Wieso dieseMinderheit in meinen Augen das Projekt so beherrscht undwieviele Menschen tatsächlich Objektinfos abfragen frage ich mich. Da erscheint mir oft mehr die Akribe eines selbstzufriedenen Sammlers als das Bestreben Überblick zu gewinnen, vorzuherrschen. Ich glaube Openstreetmap erhält seine soziale und gesellschaftliche Bedeutung ganz eindeutig durch die Karten und hier ganz besonders durch Karten für spezielle Zielgruppen vorallem im Sport- und Outdoorbereich. Nur scheint mittlerweile die Hauptaufgabe der Auswerter zu sein, wegzuschmeissen und zu raten. Vor einigen Jahren hab ich noch meine eigenen Garminkarten gemacht - mittlerweile muss man sich soviel mit filtern beschäftigen, dass ich das nicht mehr kapiere und auch die Rechenleistung für das Wegwerfen garnicht zur Verfügung hab.

Was ich allerding sehr Schade finde, ist das Menschen wie Du sich innerlich aus dem Projekt herausziehen. Okay in vielen Bereichen in Deutschland ist Openstreetmap längst im Stadium angekommen, wo verschlimmbessert wird während es gleichzeitig noch ganze Regionen - in denen ich auch noch wohne - gibt, wo OSM noch keine Substanz hat.

Ich sehe es daher als nötig an, das Ideal des "lokalen Mappers" über Bord zu werfen oder durch Patenschaftsmodelle etc zu ergänzen. Ich erlebe immer wieder, das Menschen lieber nicht beitragen, als in einem "fremden" Gebiet Informationen einzutragen - in der Erwartung, dass dort auch irgendwann eine lokale Community heranwächst. Dieses Denkmodell funktioniert aber rein logisch nicht denn die Bevölkerungsstruktur ist so, dass ein ständiges Ungleichgewicht zwischen Grösse des Gebietes und potentieller Zahl der Mapper gibt.

Selbst wenn die Community so wachsen sollte, dass es flächendeckend aktive Mapper gibt, kann die community dies überhaupt nicht verarbeiten: In den Städten stehen sich dann Mapper auf den Füssen und wir mappen Grashalme - und dieses Grashalmmapping braucht Aufmerksamkeit, was die anderen Gebiete marginalisieren wird. (Selbst mit unendlichen Mappern erreichen wir keine Konsistenz sondern schaffen nur einen Themenungleichgewicht).

Ich appeliere daher an die implizite Idee des ständigen Communitywachstum aufzugeben und - sowohl auf persönlicher als auch auf organsiatorischer Ebene - darüber nachzudenken, wohin die manpower fliessen kann.

---

edit: Das Gegenargument, dass man viele Informationen nur vor Ort feststellen kann, halte ich nicht wirklich für schlüssig. Es gibt Techniken, wie man das kompensieren kann. Gäbe es etwas sinnvolleres als "Fixme" und "note" wären sicherlich viele bereit Fragen zu beantworten. Ich erlebe von Neulingen oft einen impliziten Respekt vor dem was ich gemacht hab - weswegen Sie Dinge, die ich gemappt hab leider eben nicht verbessern oder ändern - was aber nur in einem deutlich kleineren Gebiet als in dem ich was begetragen hab, wirklich sinnvoll ist. Also hier nochmal sagen zu können: Bitte sag mir was das ist, fände ich super.

Ich verbinde das immer mit einer Einladung zu mappen in meiner Gegend (Südostschweden) - weil ich einfach auch noch kein tool gefunden hab, dass Einladungen mit der sozialen Komponente (Bereitschaft zum Dialog, Sprachbarrieren überwindenhelfen etc) weitergeben könnte.

Seawolf ich fände es also super, wenn Du Deine Erfahrungen in Gebieten einbringst, die in OSM brach liegen und diese einfach "adopierst". Ich könnte mir vorstellen, dass man so auch wieder neuen Spass am Mapping findet. Denn es gibt die Stellen, wo nichtmal grosse Seen eingetragen sind, wo man nicht einen sonder 20 Feldwege auf dem Luftbild findet --- und die sind garnicht weit weg. Und für mich funktioniert es nach Versuchen, irgendwo einen Einheitlichkeit herzustellen wunderbar als Entspannung ein solches Gebiet aufzurufen und erdet mich wieder mit dem, weswegen ich mal angefangen hab, zu mappen.

Skinfaxi wrote:

Openstreetmap entwickelt sich von einer Karte zu einer Geodatenbank - und dabei möchten viele - unter anderem ich - nicht mitmachen

Meinst Du das ernst?

chris66 wrote:

Skinfaxi wrote:

Openstreetmap entwickelt sich von einer Karte zu einer Geodatenbank - und dabei möchten viele - unter anderem ich - nicht mitmachen

Meinst Du das ernst?

ja. völlig. ich bin verschreckt durch Parkbänke, die Blickrichtungen der Aussicht haben sollen und Stadtbäumen, die genaue botanische Kennzeichnungen haben und kann mir absolut nicht vorstellen, was ich damit soll.

Das macht die Kernaufgabe mir den Überblick zu verschaffen unmöglich.

Ich ertrinke zu oft im Informationsee. Ich will markande Bäume die Landmarken sind zum navigieren benutzen - und die 30 Bäume darum machen es erstmal nötig ein Fernglas auszupacken und generieren die Notwendigkeit, mir zu merken, ob der markande Baum eine Birke oder eine Eiche ist.

Ich werde oft genötigt, tags zu benutzen oder wegzuklicken, die nach meiner Meinung wenig Sinn haben. Allein die Frage wer auf einem Waldweg fahren darf, ist so komplex, weil es offensichtlich nicht genügt zu sagen "Ottonormalnutzer nicht". Ich kann mir einfach nicht vorstellen, dass es Forstwirte gibt, die nicht wissen, dass sie ihre Wege forstwirtschaftlich Nutzen dürfen.

Also statt mir einen Überblick zu geben, muss ich genau das Gegenteil machen.

---

edit --- und was mich bei diesem Ertrinken strudelartig herunterzieht, ist dass ich es einfach nicht schaffe, eine Leseregel für die OSM Karten zu entwickeln. Implikationen funktionieren nie: An manchen Stellen hat eine popel Bushalte soviele Tags dass ich rein intuitiv und automatisch denke "das ist die wichtige Haltestelle" weil die grössere Umsteigehaltestelle 100meter weiter - die auch in der Natur wesentlich mehr Infrastruktur hat - halt nicht Mircogemappt ist.

und dieses sich alle paar Minuten auf ein völlig neues Lesemuster einzustellen, verbraucht bei mir unheimlich viel Energie. --- /edit

chris66 wrote:

Skinfaxi wrote:

Openstreetmap entwickelt sich von einer Karte zu einer Geodatenbank - und dabei möchten viele - unter anderem ich - nicht mitmachen

Meinst Du das ernst?

Die Frage kam mir auch sofort in den Sinn. OSM ist eine Geodatenbank, aus der sich Karten generieren lassen, und das war von Anfang an so geplant und umgesetzt, insofern kann ich mir eine lineare Entwicklung von einer Karte zur Geodatenbank, wie sie dieser Formulierung zugrundeliegt, nicht vorstellen. Wo hört Karte auf, wo fängt Geodatenbank an?

Wahrscheinlich bezieht sich dieser Satz auf eine willkürlich gezogene Grenze der Detailtiefe (nach dem Motto „Straßenverlauf = Karte, Straßengrün = Geodatenbank“ oder „Straßenkreuzungen = Karte, Abbiegespuren = Geodatenbank“), aber diese Grenze ist naturgemäß nicht fest und bleibt dem persönlichen Ermessen des Mappers überlassen.

Ich persönlich finde es beispielsweise zur Orientierung auf Feldwegen hilfreich, Gebüschstreifen zu mappen, weil ich beim Blick auf die Karte dann gleich weiß: An, da hinten am Hang geht es hoch, links vom Gebüsch. Andere mögen das schon als Micromapping betrachten, ihnen reicht das Netz der Feldwege und das „Sie sind hier“-Symbol auf dem GPS-Display. Ich persönlich sehe andererseits keinen rechten Sinn darin, einzelne Straßenlaternen samt ref=*, Bauform, Lichtfarbe und elektrischer Leistung zu mappen, aber andere werden damit glücklich – na und? Mir macht es Spaß, eckig gemappte Straßenkurven (und Eisenbahn-!) sauber auszurunden, weil das gerenderte Ergebnis dann sehr viel professioneller aussieht, für andere ist das Spielkram, weil das Routing im Navi zugegebenermaßen auch mit eckigen Kurven funktioniert und sie weniger Speicherplatz beanspruchen. Das etwas Chaotische an dem Projekt macht für mich einen Reiz aus.

Also trage ich weiter das bei, was ich persönlich in einem digitalen Abbild der Welt für sinnvoll halte, und freue mich, wenn andere es gewinnbringend nutzen können.

--ks

kreuzschnabel wrote:

Also trage ich weiter das bei, was ich persönlich in einem digitalen Abbild der Welt für sinnvoll halte, und freue mich, wenn andere es gewinnbringend nutzen können.

+1 - sehr gut geschrieben ...

kreuzschnabel wrote:

Ich werde oft genötigt, tags zu benutzen oder wegzuklicken, die nach meiner Meinung wenig Sinn haben. Allein die Frage wer auf einem Waldweg fahren darf, ist so komplex, weil es offensichtlich nicht genügt zu sagen "Ottonormalnutzer nicht". Ich kann mir einfach nicht vorstellen, dass es Forstwirte gibt, die nicht wissen, dass sie ihre Wege forstwirtschaftlich Nutzen dürfen.

Tags wegklicken? Was meinst du damit? Hast du mal ein konkretes Beispiel? Ich habe nicht das Gefühl, dass mir Details aufgezwungen werden und ich diese erstmal aktiv unterdrücken muss, wenn ich z.B. Osmand nutze, und ich muss da auch nichts „wegklicken“, wenn an einem Baum, an dem ich vorbeigehe, das botanische Taxom drangemappt ist.

--ks

kreuzschnabel wrote:

Die Frage kam mir auch sofort in den Sinn. OSM ist eine Geodatenbank, aus der sich Karten generieren lassen, und das war von Anfang an so geplant und umgesetzt, insofern kann ich mir eine lineare Entwicklung von einer Karte zur Geodatenbank, wie sie dieser Formulierung zugrundeliegt, nicht vorstellen. Wo hört Karte auf, wo fängt Geodatenbank an?

--ks

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.

kreuzschnabel wrote:

Ich persönlich sehe andererseits keinen rechten Sinn darin, einzelne Straßenlaternen samt ref=*, Bauform, Lichtfarbe und elektrischer Leistung zu mappen, aber andere werden damit glücklich – na und?
--ks

Warum na und?

1) 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.

2) 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.

kreuzschnabel wrote:

Mir macht es Spaß, eckig gemappte Straßenkurven (und Eisenbahn-!) sauber auszurunden, weil das gerenderte Ergebnis dann sehr viel professioneller aussieht

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.

Kontinentalverschieber wrote:

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.

.

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.

wegavision wrote:

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.

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.

seawolff wrote:

Ich habe mich laut "How did you contribute" am 16. Juli 2008 bei OSM angemeldet und seitdem
473 348 Nodes, 63 563 Ways und 614 Relationen angelegt (und einige mehr bearbeitet).

(Viel richtiges nicht zitiert...)

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!

Gruß,
Zecke

Skinfaxi wrote:

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

R0bst3r wrote:

• 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?
  

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.
  

MKnight wrote:

• 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:

Skinfaxi wrote:

...ich bin verschreckt durch Parkbänke, die Blickrichtungen der Aussicht haben sollen und Stadtbäumen, die genaue botanische Kennzeichnungen haben und kann mir absolut nicht vorstellen, was ich damit soll.

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.

Sir_Blight wrote:

Ich bin überzeugt: gäbe es in irgendeiner Art eine Übersicht aller tags die auch tatsächlich von jemandem* ausgewertet werden ...

Gibt es doch: https://wiki.openstreetmap.org/wiki/Taginfo/Projects bzw. https://taginfo.openstreetmap.org/projects - nur es benutzt natürlich fast niemand 🙁

Man muss sich halt als Entwickler die Mühe machen, "seine" Tags zu beschreiben.

Gruss
walter

ps: ja. auch ich schlampe da, aber einiges von mir ist drin.

R0bst3r wrote:

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?
  

[...]

Geht mir als Gelegenheitsmapper-Rookie ebenso. Relationen sind mir immer noch ein Graus, Public-Transport bloss die Finger weg...

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.
  

[...]

• Verbindliche Presets für alle Editoren für Anfänger und Warnungen bei nicht gebräuchlichen Tags würden schon viel helfen.
  

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.

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.

+1
Dazu bräuchte man wohl auch eine Working Group bei der OSMF, oder?

Kontinentalverschieber wrote:

kreuzschnabel wrote:

Mir macht es Spaß, eckig gemappte Straßenkurven (und Eisenbahn-!) sauber auszurunden, weil das gerenderte Ergebnis dann sehr viel professioneller aussieht

Aber hoffentlich noch mit einer sinnvollen Genauigkeit und nicht so.

Graus! Nein!

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.

--ks

Sir_Blight wrote:

MKnight wrote:

• 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.

+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.

kreuzschnabel wrote:

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.

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.

MKnight wrote:

hier wird besprochen, Tagging für Hundekotbeutelspender abzuschaffen, ich brauch die nicht, für mich ist der Gedankengang trotzdem inakzeptabel.

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.

--ks

Kontinentalverschieber wrote:

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.

Hui, "Wege vereinfachen" (Shift-Y) in JOSM ist aber ganz schön radikal eingestellt per default, und wollte mir den Weg auf 20 Nodes vereinfachen. 🙂

Habe den Schwellwert auf 0.1 gesetzt und die Dichte damit um 50% reduziert.

Nach all den zwischenzeitlichen Posts scheint mir das vorerst Wichtigste die Definition eines allgemeinverbindlichen Tagging-Gold-Standards. So etwas würde das Projekt meines Erachtens deutlich nach vorne bringen. @woodpeck: Wäre das nicht eine Aufgabe um die sich der Vorstand bemühen sollte?

Gruß Klaus

toc-rox wrote:

Nach all den zwischenzeitlichen Posts scheint mir das vorerst Wichtigste die Definition eines allgemeinverbindlichen Tagging-Gold-Standards. So etwas würde das Projekt meines Erachtens deutlich nach vorne bringen. @woodpeck: Wäre das nicht eine Aufgabe um die sich der Vorstand bemühen sollte?

Prinzipiell würde ich klarere, verbindlichere Standards zumindest in Kernbereichen sehr begrüßen. Ich denke jedoch so etwas darf aber nicht übers Knie gebrochen werden oder an der Community vorbei von Oben verordnet werden, wenn es brauchbar sein und Akzeptanz finden soll. Ich denke man sollte erst mal folgendes klären:

In welchen Bereichen braucht man verbindliche Regeln?

Wie sollen die zustande kommen? Brauchen wir vielleicht formalisierte Diskussions- und Abstimmungsprozesse?

Wie sollen diese Regeln verbindlich festgehalten werden?

Sollen diese Regeln trotzdem irgendwann geändert werden dürfen und falls ja wie?

Schönes Statement seawolff!

Für einige scheint es hier nur unzureichend gelöste Probleme zu geben. Und das kann sehr frustrierend sein. Man hofft es ändert sich etwas, vielleicht setzt man sich sehr ein, zu einer Lösung zu kommen. Und wenn sich dann doch nichts verbessert, dann kann das sehr frustrierend sein und entweder zieht man sich dann ganz vom Projekt zurück oder sucht sich eine Nische, in der man sein Ding machen kann. Das ist zwar alles okay, aber auf Dauer wird das dem Projekt schaden.

seawolff wrote:

Selbst beim Straßen- und Wegenetz, dass man als Kernkompetenz von OSM vermuten würde, gibt es abhängig vom letzten Bearbeiter deutliche Unterschiede. Einige Mapper entscheiden streng nach amtlicher Klassifizierung, andere nach gefühlter Verkehrsbedeutung und manche haben weitere Kriterien.

Hmm, da sieht man dann, wer das Wiki gelesen hat und wer nicht. Also ich bin jetzt von DE:highway zu DE:Highways zu Attributierung von Straße in Deutschland gesprungen, und konnte nicht wirklich Widersprüche finden, sondern eigentlich immer den (teils fetten) Hinweis, dass man sich eben NICHT nach amtlicher Klassifizierung richten soll ... was vermutlich aber gerade den Gesetzes-Verordnungs-Reitern trotz dieses Wissens schwer fällt.

seawolff wrote:

Bei vielen Objekten fehlen Tags um abzuschätzen, ob sie lokal, regional oder überregional relevant sind (Bäume, Flugplätze, Kanäle, Attraktionen).

Subjektives Empfinden, also ungeeignet für OSM ... ich erinnere mich da wieder an place:importance 🤣

seawolff wrote:

Aber aus OSM ist leider keine universelle Geodatenbank geworden, mit der man Fragen nach der Anzahl, Gesamtlänge oder Fläche von bestimmten Objektklassen in einem Gebiet beantworten kann.

Nicht? Beispiel: ich hole mir aus dem Thüringen Extrakt der Geofabrik mit wambachers-boundariy-poly für Schleusegrund ein bestimmtes Gebiet, jage diese Daten durch osmium_road_length und erhalte separiert für alle highway die Länge...
Oder die Anzahl der Bänke mit Rückenlehne in Schleusegrund ist doch z.b. mit Overpass Turbo ohne weiteres möglich... (klar, man muss sich halt in eine "Abfragesprache" einarbeiten ... wofür es aber eine mehr als ausreichende Dokumentation sowie vielen Beispiel gibt)

Skinfaxi wrote:

Openstreetmap entwickelt sich von einer Karte zu einer Geodatenbank - und dabei möchten viele - unter anderem ich - nicht mitmachen

Sorry, das klingt jetzt vielleicht richtig hart, aber dann bist du wohl besser bei OpenGeoFiction aufgehoben, da kannst du gerne deine Karte "malen". OpenStreetMap war von Anfang an eine Geodatenbank ... ja, am Anfang vielleicht auch unter anderem mit dem Hauptzweck daraus eine grafische Karte abzuleiten.

Skinfaxi wrote:

Ich werde oft genötigt, tags zu benutzen oder wegzuklicken, die nach meiner Meinung wenig Sinn haben.

Auch hier ein großes Sorry, dass man dich dazu zwingt etwas zu tun, was du nicht möchtest? 🙄

Skinfaxi wrote:

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.

Also wenn in einem Gebiet 150 Hydranten mit verschiedenartigem Wasser (Abwasser, Brauchwasser, Trinkwasser) gefüllt sind und du, warum auch immer, Trinkwasser benötigst, wirst du froh sein, dass das jemand so detailliert gemappt hat, und du NICHT mit einem großen Schraubenschlüssel und Chemielaboratorium jeden einzelnen Hydranten prüfen musst, bis du bei dem einen Hydranten, der dir Trinkwasser bietet angekommen bist 😉

Ein paar andere mir wichtige zu kommentierende Dinge haben bereits Trockennasenaffe sowie kreuzschnabel kommentiert.

Letztendlich würde aber auch ich mir durchaus wünschen, dass es eine höhere und bessere Konsistenz des Taggings geben könnte, v.a. da wir ja für/in eine Datenbank taggen, und da ist Konsistenz halt nun mal das A und O ... langsam frage ich mich, ob die OpenStreetMap Datenbank, welche ja eigentlich strukturiert und relational abgebildet ist, einer der ersten Vorläufer für die später entwickelten NoSQL Datenbank waren, wo man meistens nur einfach unstrukturierte Dokumente reinklopft 😎

Trockennasenaffe wrote:

Prinzipiell würde ich klarere, verbindlichere Standards zumindest in Kernbereichen sehr begrüßen.

Es gibt doch eigentlich diese proposed und approved features. Das ist ja eigentlich eine gute Sache, mir scheint es nur ein wenig zu umständlich und vielleicht auch zu irrelevant. Vielleicht kann man mal schauen wie so was in anderen Projekten gemacht wird und sich da Inspirationen holen um den Abstimmungs- und Meinungsfindungsprozess hier dazu zu nutzen um klarere und verbindlichere Regelungen zu finden. Hier bspw. bei Wikidata: https://www.wikidata.org/wiki/Wikidata: … roposal/de

Ich kann mich seawolff nur anschließen. Ich bin zwar erst 2 Monate nach ihm zu OSM gestoßen :-), aber es geht mir im Prinzip genauso: Am Anfang war ich sehr aktiv und begeistert dabei, habe viel mitdiskutiert und versucht neue Tags zu etablieren und bestehende Probleme zu lösen. Mittlerweile habe ich in weiten Teilen kapituliert. Ich ergänze weiterhin fehlende Wege oder korrigere nicht zutreffendes Tagging, wenn ich im Gelände unterwegs bin. Im Forum betätige ich mich zwar als Mod, aber schüttle meistens nur noch für mich den Kopf wenn die gleichen Diskussionen seit 2008 immer wieder hochkommen (Spitzenreiter ist glaube ich „Radweg“), jedes mal ohne Ergebnis.

Es werden zwar immer mehr Dinge erfaßt, aber ich beobachte auch daß die Qualität und vor allem die Nutzbarkeit der OSM Daten stetig schlechter wird. Nachdem ich mich als Informatiker beruflich mit Datenstrukturen auseinandersetzen darf und die Regeln für meinen eigenen Kartenserver von Null aufgebaut habe und ständig pflegen muß, denke ich daß ich ein ganz gutes fachliches Verständnis dafür habe. 2008 war ich total idealistisch von der Idee begeistert, an einer freien Geodatenbank für Alle mitzuarbeiten – aber OSM ist nur noch mit sehr viel Fachwissen und Erfahrung auswertbar. Ich mußte selbst auch schon mehrfach als Berater tätig werden, für Firmen oder auch in den Anfängen des Graphhopper Projekts, die an dem oftmals chaotischen, unlogischem Tagging und lückenhaften, widersprüchlichen und unzuverlässigen Wikieinträgen erst mal verzweifelt waren.

kreuzschnabel wrote:

OSM ist eine Geodatenbank, aus der sich Karten generieren lassen, und das war von Anfang an so geplant und umgesetzt

Genau das ist das Problem: OSM ist immer weniger eine für Kartographie geeignete Geodatenbank und wird immer mehr zu einer schlecht strukturierten Detaildatensammlung. Dabei geht es gar nicht darum, wie detailliert man persönlich mappen will, was „wichtig“ ist oder „in die DB reindarf“. Die Datenbank ist eigentlich groß genug für alles.

Das Problem sind die mangelhaften Strukturen, die es immer schwerer bis unmöglich machen, die notwendigen Informationen für einen bestimmten Abstraktionslevel wieder mit vernünftigem Aufwand und vernünftiger Zuverlässigkeit aus der Datenbank herauszulesen.

Ein Beispiel für eine gut auswertbare, logische Struktur (die bis vor kurzem noch so funktioniert hat) wäre z.B.

• Level 1 tourism=information: Ein Renderer kann global entscheiden ob er diese Klasse von Objekten anzeigen will oder nicht. Alle Objekte sind „gleich groß/wichtig“ (Infopoints, Wandertafeln) und können sinnvoll mit einem (i) dargestellt werden.
  
• Level 2 tourism=information + information=office, hikingmap, citymap, etc.: Ein Renderer hat Regeln um bestimmte Objekte mit unterschiedlichen Icons anzuzeigen
  
• Level 3 tourism=information + information=hikingmap + name: Ein spezialisierter Renderer wertet auch noch die Detailinfos aus
  

Diese Struktur wurde vor Kurzem zerstört, als mit den zusätzlichen Werten information=route_marker und information=trail_blaze plötzlich einzelne Wanderschildchen unter dem gleichen Haupttag hinzukamen, die von Größe, Anzahl und Darstellung nicht zu Infobüros und Hinweistafeln passen. Dadurch funktioniert eine Level1-Auswertung nicht mehr, jeder Auswerter ist gezwungen, eine Level2 Auswertung zu machen und die unpassenden Werte wieder herauszufiltern, ansonsten ist z.B. eine Level1-Karte windpockenartig mit sinnlosen (i)s überflutet. Und natürlich muß der Auswerter erst mal von dieser Besonderheit wissen, denn logisch ist es ja nicht und bis letztes Jahr hat es noch einfach funktioniert.

Leider gibt es eine Vielzahl von solchen Verschlechterungen in der Datenstruktur, die in Summe die Latte für einen Auswerter verdammt hoch legen und ständige Aufmerksamkeit und Nachpflege erfordern – und dazu schon immer ungelöste Probleme. Hier nur ein paar Beispiele, die mir spontan einfallen:

• zum Haupttag inkompatible Erweiterungen von subtags wie im Beispiel oben
  
• willkürliche Umdefinition und Verkomplizierung von Tags im Wiki z.B. Höhenangaben genormt in WGS84 anstatt dem allgemein üblichen (und vorher auch im Wiki verankerten) Meter über Normal Null. Stellt alle Höhenangaben in Frage, zum Glück nur mit geringer praktischer Abweichung.
  
• nachträgliche Umdefinition bestehender Tags. z.B. natural=tree von „Signifikanter Baum“ auf „irgendein Baum“. Dabei gingen 50000 größtenteils signifikante Bäume ohne weiteres Tagging von 1500 Usern einfach zwischen den massenhaft importierten unbedeutenden Bäumen verloren
  
• fehlende Klassifizierung: Objekte werden zwar mit jeder Menge Level3 Detailtags eingetragen, aber es fehlen Level1 und Level2 Tags mit einer Klassifizierung für eine kartographische Abstraktion
  
• Negation des Haupttags in einem Detailtag. z.B. amenity=restaurant, disused=yes. Erzwingt eine Level3 Auswertung von allen Auswerten, führt zu falscher Anzeige von ungültigen Objekten bei allen Auswertern die nur eine Level1 Auswertung benötigen/machen.
  
• unnötig komplexes Mapping: wer mag kann die Datenbank mit unnötiger Komplexität für andere user unbearbeitbar und extrem schwer auswertbar machen. z.B. Multipolygone wo einfache Polygone ausreichend wären, Zerstückelung durchgehender ways um sie an MPs zu kleben
  
• unscharfe und mehrdeutige Tags: z.B. highway=path, bicycle=yes Das kann ein 2 Meter breiter, gut befestigter Spazierweg sein (nur ohne blaues Schild) oder ein handbreiter Trampelpfad im Gelände. Workarounds über zusätzliche Tags wie Wegbreite funktionieren nicht, da sie aufwändige Spezialauswertungen erzwingen und die nötigen Zusatztags nur selten verwendet werden.
  
• mangelndes Bewußtsein für die Probleme: Für das obige Problem wurde schon vor langer Zeit das Tag highway=trail vorgeschlagen, das Trampelpfade eindeutig gekennzeichnet hätte und die Verwechslung mit dem (unglücklich gewählten) path beendet hätte. Es konnte sich aber nicht durchsetzen.
  
• fehleranfällige Taggingempfehlungen und daraus resultierende Fehler: z.B. ist im Wiki immer noch das Schema access=no, bicycle=yes dokumentiert. Das ist fast immer falsch, da alle nicht ausdrücklich erwähnten Verkehrsteilnehmer verboten werden und die "exotischeren" angefangen beim Reiter meist vergessen werden.
  
• unzureichende API. Die Wirklichkeit ist komplizierter als es sich mit ways und nodes abbilden läßt. Die API wurde nie dahingehend weiterentwickelt, daß sie z.B. echte Polygone und Multipolygone unterstützt. Polygone ergeben sich nicht aus der Geometrie, sondern manchmal aus dem Haupttag, manchmal nur in Kombination mit dem Subtag area=yes. Multipolygone werden als Dauer-Workaround als relations dargestellt - eine weitere unnötige und unerwartete Stufe der Komplexität bei der Auswertung und eine große Hürde für neu eingestiegene Mapper.
  

toc-rox wrote:

- Und: Wohin wollen wir?

Das ist eine sehr gute Frage - und ich fürchte es gibt auch hier keine Einigkeit.

Ich bin der Ansicht daß das freie Taggen von OSM eine super Idee war als es galt, gigantische weiße Flecken zu füllen und eine vage Information besser war als gar keine Information. Aber ab einer gewissen Datenmenge, Datendichte und Komplexität bräuchte man verbindliche Regeln und eine durchdachte Struktur um sich weiter zu verbessern. Ansonsten werden die Daten zwar noch mehr, aber gehen auch wieder kaputt und werden schlechter nutzbar. Auch für neue Mapper wäre es bedeutend einfacher, ein paar feste Regeln zu lesen als lange Diskussionsthreads ohne Ergebnis.

Aber als Resultat vieler Diskussionen mußte ich mich damit abfinden daß verbindliche Regeln bei OSM nicht mehrheitsfähig sind. Ich würde erwarten daß vielfach wieder die Antwort kommt "Es gibt doch gar kein Problem". Es ist auch zu berücksichtigen, daß OSM ein globales Projekt ist, in dem es auch Politik zwischen verschiedenen Ländercommunities gibt.

Nop wrote:

...

Genau das ist das Problem: ...

Das Problem sind die mangelhaften Strukturen, die es immer schwerer bis unmöglich machen, die notwendigen Informationen für einen bestimmten Abstraktionslevel wieder mit vernünftigem Aufwand und vernünftiger Zuverlässigkeit aus der Datenbank herauszulesen.

...

Danke, die Sicht des Auswerters sehen leider nur wenige.
Schön zusammengefasst, schöne Beispiele.

Was Nop hier schreibt sind ein paar wirklich wichtige Erkenntnisse. Ich will zu ein paar davon mal meinen Senf dazugeben, bzw. versuchen, da ein paar allgemeine Ideen draus zu gewinnen. Probleme, die aufgezählt wurden:
1. Schlecht benannte Tags. Was garnicht mal ursprünglich schlecht gewesen sein muss, aber sich langfristig halt als problematisch herausgestellt hat. natural=tree wäre ein Beispiel - das ging gut, solange man mit dem Mappen von Hauptstraßen befasst war, deshalb eh nur die wichtigsten Bäume eingetragen hat und die Community und die Anzahl der Tags überschaubar war, so dass die meisten wussten, dass das ein besonderer Baum sein soll. Mittlerweile ist es gescheitert, weil es offensichtlich nicht intuitiv ist. highway=path wäre ein weiteres Beispiel, das ähnliche Probleme aufweist (hier eben, dass Leute Trampelpfade damit erfassen, obwohl das so nie gedacht war - das Proposal in dem klar wird, worum es geht, wurde ja erst die Tage wieder ausgegraben), ein drittes schon oben genanntes landuse=farm.
2. Bereits gelöste Probleme, die wiederkommen. Für das selbe Problem wie bei disused=yes haben wir ja uns ja für Straßen auf z.B. highway=construction, construction=* geeinigt, was möglicherweise auch nicht perfekt, aber doch wohl besser, was die Auswertung angeht.
3. Fehlendes Verständnis für die Auswerter. Das Dogma war und ist ja eher "mal in die DB schütten, soll der Auswerter schauen, was er braucht". Ist ja auch nicht ganz falsch und hilft eben, neue Konzepte ausprobieren zu können. Aber wenn man die Auswerter ganz aus den Augen verliert (und die meisten Mapper werten nunmal nicht selbst aus, also haben sie die Perspektive einfach nicht) gibt es eben die angesprochenen Probleme.
4. Die Schwierigkeit, durchdachte Konzepte durchzusetzen. Es gab ja in einigen Nischen schon Proposals, die versucht haben, den Wildwuchs abzuschaffen und durch ein einheitliches Konzept zu ersetzen, das Probleme wie von Nop bei tourism=information vermeiden könnte. Aber außerhalb von extremen Nischen (wie vllt. Eisenbahntagging) scheitern solche Initiativen fast immer - weil auch ein angenommenes Proposal mit ein paar Dutzend Stimmen bestenfalls nichts wirklich was aussagt, Auswerter (vor allem der einflussreiche Stil der Hauptkarte, also OSM-Carto aktuell) nicht direkt mitziehen, sondern nur wenn sich das Tagging langfristig durchsetzt, etc. So kommt am Ende nur noch mehr Wildwuchs raus, weil mancher die neuen Varianten nutzt, in der Hoffnung, dass sie die alten verdrängen werden, während andere die alten Varianten nutzen, weil sie eben noch ausgewertet werden (oder weil man die schon immer so verwendet hat - oder weil sie halt noch im Wiki stehen - oder oder oder).
5. Wiki-Wildwuchs zwischen verschiedenen Sprachen und auch innerhalb einer Sprache. Schwer auch, den zu beseitigen. Verändert man was, weil z.B. ein Proposal angenommen wurde, wird es gleich wieder reverted mit Hinweis darauf, dass die alte Variante aber ja viel weiter verbreitet ist, etc.

Was mich wieder, wie oben, dazu bringt, dass wir ein Konzept bräuchten, um Autorität zu schaffen. Nicht in der Form, wie es vielleicht bei der Wikipedia existiert und zu Recht von vielen abgelehnt wird. Aber eben doch mehr, als bisher existiert. Insbesondere sollte es meiner Meinung nach keine Autorität geben, die neue Tags verbietet (sei es wegen Irrelevanz, Wikipedia lässt grüßen, oder weil man da ja schon andere Möglichkeiten für habe), weil die Weiterentwicklung eben notwendig ist, aber es sollte eine Autorität geben, die alte Tags konsequent abschaffen kann, auch durch gezieltes Umtaggen, etc., wenn besser Lösungen gefunden sind (was eben auch sein kann, bevor die neue Lösung 'von selbst' eine Mehrheit im Tagging erreicht, was gegen den großen Datenbestand nur noch schwer möglich ist).

Drei Konzepte dazu:
1. Wie oben vorgeschlagen: Umfragen, mit denen verbindliche Entscheidungen getroffen werden können - ausgehend von der Gesamtheit der Mapper als Autorität. Die Ergebnisse sollten nicht für alle Ewigkeit verpflichtend sein, aber die Basis für breit angelegtes Umtagging, Änderungen bei der Auswertung, Anpassungen im Wiki. Wenn später Änderungen nötig werden, sollte aber wieder der übliche Weg gelten (also, neue Tags darf man jederzeit auch gegen diese Entscheidung ausprobieren - nur die alten sollten dadurch verschwinden).
2. Eine informelle Arbeitsgruppe der Auswerter. Ob als Mailingliste oder sonstwie. Das könnte bestimmte Umstellungsprozesse vereinfachen ("Wir werfen alle in 8 Wochen landuse=farm raus, dann hat es sich damit..."), vor allem aber könnte man gemeinsam auf Proposals und andere Entwicklungen achten, die Auswertung unnötig erschweren und möglichst frühzeitig eingreifen und Unterstützng anbieten, um bessere Lösungen zu finden.
3. Ein Wikiarbeitsteam und verbindliche Wiki-Regeln. Beispielsweise sollte außer für wirkliche länderspezifische Details immer nur die englische Seite für ein Tag ausschlaggebend sein, die anderen Seiten nur Übersetzungen davon. Das Team wäre dafür zuständig, diesen Zustand herzustellen und zu erhalten. Verbesserungen an einer andersprachlichen Seite würde in die englische Version eingepflegt, Änderungen an der englischen Version in die anderen Sprachen übertragen. Außerdem würde das Team veraltete Beschreibungen, ob sie jetzt über die Jahre oder die in 1. vorgeschlagenen Abstimmungen veraltet geworden sind, anpassen. Natürlich sollten diese Leute neutral sein und nicht ihre eigene Meinung durchdrücken, sondern den Konsens, wo er schon da ist, einfach konsequent ins Wiki schreiben.

Ob auch nur eines der drei realistisch umsetzbar ist, sei mal dahingestellt. Vielleicht taugt es aber ja als Diskussionsgrundlage.

Okay, also ich habe mich ja auch schon damit beschäftigt, wie ich Daten bekomme, die ich benötige ... aber das Problem mit natural=tree kann ich irgendwie, bzw. die Argumentation oder Interpretation dahinter nicht nachvollziehen, vielleicht auch weil ich die geschichtliche Entwicklung dazu nicht kenne, wie wohl auch vermutlich viele andere hier u.v.a. die, die jetzt noch neu dazu kommen.

Also natural=tree ist doch erstmal einfach nur ein Baum (für mich in Nop's Sprache Level 1), und man hat damals, vor Jahren, als Auswerter gemeint, ach das wird ja NUR erfasst, wenn er wichtig ist, also zeige ich den auch gleich mal an, hineininterpretiert?!
Naja, und da gibt es dann auch noch eine Karte eines gewissen Nop, die leaf_type (Level 2) auswertet und das entsprechende korrekt Icon rendert
Und hat man dann erst irgendwann mit der Zeit und wachsender Anzahl und Unübersichtlichkeit an Bäumen in der Karte (vielleicht festgestellt, dass die erste Interpretation nicht ganz so richtig war) denotation (wäre dann wohl Level 3) erfunden, mit dem man dann wieder "wichtige" Bäume (Landmarken, wie es Skinfaxi gerne hätte) definieren kann?! 🙄

PS: Und wenn es so eine "nachträgliche" Umdefinition von natural=tree kam, dann haben wohl die "mechanical edit" gegner ganze Arbeit geleistet und bei der Umdefinierung ein zusätzliches taggen von denotation verhindert? Echt jetzt? Dann läuft definitiv richtig was schief bei OSM, da man das eine nicht ohne das andere machen kann, dann fehlt uns wirklich eine "Führung"...

Harald Hartmann wrote:

Also natural=tree ist doch erstmal einfach nur ein Baum (für mich in Nop's Sprache Level 1), und man hat damals, vor Jahren, als Auswerter gemeint, ach das wird ja NUR erfasst, wenn er wichtig ist, also zeige ich den auch gleich mal an, hineininterpretiert?!

Im Wiki steht bis heute:

Einzelner oder signifikanter Baum [1]

https://wiki.openstreetmap.org/wiki/DE: … ral%3Dtree

Und wie soll das mit der hier von einigen hier geforderten "Autorität" funktionieren, wenn sich die Mapper nicht mal an die Autorität "Wiki" halten?

[1] Wobei mit "einzeln" vermutlich freistehend/isoliert gemeint ist.

Harald Hartmann wrote:

Skinfaxi wrote:

Openstreetmap entwickelt sich von einer Karte zu einer Geodatenbank - und dabei möchten viele - unter anderem ich - nicht mitmachen

Sorry, das klingt jetzt vielleicht richtig hart, aber dann bist du wohl besser bei OpenGeoFiction aufgehoben, da kannst du gerne deine Karte "malen". OpenStreetMap war von Anfang an eine Geodatenbank ... ja, am Anfang vielleicht auch unter anderem mit dem Hauptzweck daraus eine grafische Karte abzuleiten.

Skinfaxi wrote:

Ich werde oft genötigt, tags zu benutzen oder wegzuklicken, die nach meiner Meinung wenig Sinn haben.

Auch hier ein großes Sorry, dass man dich dazu zwingt etwas zu tun, was du nicht möchtest? 🙄

Um nicht nochmal alles zu wiederholen:
a) was ich damit meine habe ich weiter unten ausgedrückt. Oder bezugnehmend auf Nope: Ich brauche Ebene 1, 2 und 3 und nicht 4 - 207. Und eine Datenstruktur muss sich ja immer nach dem kleinsten gemeinsamen Nenner richten. Gibt es jetzt 207 Detailebenen wird 1,2 und 3 nurnoch mit herumgefummel eintragbar.

Ich hab nix gegen eine technische Datenbank, sondern dagegen dass nicht die für die ABSTRAKTION notwendigen Informationen eingetragen werden, sondern ZUSÄTZLICHE - jedenfalls so lange das nicht konfliktfrei im eigenen Raum geht.

b) Auch hier habe ich Dir klare Beispiele ausgeführt. Natürlich wird man oft genug GEZWUNGEN sich mit Detailmapping auseinanderzusetzen - jedenfalls solange ich den Respekt aufbringe, nicht seinen eigenen Käse einfach drüberzulegen. Ich kann bei einem Segmentierten Kreisverkehr den Kreisverkehr nicht mehr als ganzes Bearbeiten sondern muss jede blödes Segment für sich bearbeiten. Was manchmal Sinn macht (andere Fussgängerouten über die Mitte) etc ist in anderen Fällen einfach nur aufwendig. Natürlich generiert ein "hier sind Pflastersteine in der und der Qualität verlegt" den Impuls nach einer Strassenrenovierung zu gucken, ob das noch stimmt (und ich meine eigentlich auch die soziale Pflicht, das zu verbessern wenns falsch ist).

Wenn jemand anfängt das tag campground zu zerschiessen, in dem er durch die Einführung von Subtags den Sinn des Haupttags in Frage stellt MUSS ich (unter der Bedingung die Funktionalität zu erhalten) sämtliche vorher impliziten Informationen allen meinen Objekten einzeln hinzufügen...

Ja, gezwungen werde ich natürlich nur dann, wenn ich der Meinung bin, dass meine Arbeit einen Sinn haben soll.

Im Klartext: Wenn Du zum Selbstzweck mappst und dabei garkeinen Gedanken an das grosse Ganze verschwendest, lass es bleiben. Also konkret: Ist das wartbar? Hat es eine Chance auf Konsistens - zumindest in einer relevanten Zone? Alleine damit wäre schon viel gewonnen.

errt wrote:

Drei Konzepte dazu:
1. Wie oben vorgeschlagen: Umfragen, mit denen verbindliche Entscheidungen getroffen werden können - ausgehend von der Gesamtheit der Mapper als Autorität. Die Ergebnisse sollten nicht für alle Ewigkeit verpflichtend sein, aber die Basis für breit angelegtes Umtagging, Änderungen bei der Auswertung, Anpassungen im Wiki. Wenn später Änderungen nötig werden, sollte aber wieder der übliche Weg gelten (also, neue Tags darf man jederzeit auch gegen diese Entscheidung ausprobieren - nur die alten sollten dadurch verschwinden).

Aus der Forschung zu sozialen Bewegungen ist bekannt, dass Versuche, Menschen einzubinden, die dies nicht wollen dazu führen, dass sie sich garnicht mehr engagieren.

Bei solchen Verfahren braucht es meines Erachtens eine klaren Willenserklärung des Mitglied / Beitraggebers dass er sich mit solchen Fragen beschäftigen will. Also auch eine Mögilchkeit, das einfach wegzuwählen ohne schlechtes Gewissen hervorzurufen.
2. Eine informelle Arbeitsgruppe der Au … zu finden.

Hm, das informell steht jetzt in einem merkwürdigen Widerspruch zu dem Prinzip oben. Wieso informell? Eine Arbeitsgruppe mit Beschlussrechten in die jeder Auswerter der nachweisbar mind. 100 Karten pro Monat absetzt eine Stimme hat ist doch okay und transparent (solange die Möglichkeit der Mitarbeit für jeden besteht).

3. Ein Wikiarbeitsteam und verbindliche … schreiben.

An dem Versuch, eine weltübergreifenden Standart zu schaffen, verheben wir uns doch - und keiner blickt mehr durch. Ich finde es völlig in Ordnung, wenn genau umgekehrt vorgegangen wird: Die lokalen Chapter machen ein Wiki, dass für das abgegrenzte Gebiet verbindlich ist. Hier können dann aussagekräftige, lokal relevante Beispiele und Fotos genommen werden und der landesspezifische "Goldstandart" definiert werden. Und danach wird das so weit es geht international synkronisiert - am besten von der Arbeitsgruppe, die Du unter 2 beschrieben hast. Das wird wesentlich konkreter und begreifbarer - und ist im Moment sowie defacto der Status quo.

Nop wrote:

OSM ist eine Geodatenbank, aus der sich Karten generieren lassen, und das war von Anfang an so geplant und umgesetzt

Genau das ist das Problem: OSM ist immer weniger eine für Kartographie geeignete Geodatenbank und wird immer mehr zu einer schlecht strukturierten Detaildatensammlung. Dabei geht es gar nicht darum, wie detailliert man persönlich mappen will, was „wichtig“ ist oder „in die DB reindarf“. Die Datenbank ist eigentlich groß genug für alles.

Das Problem sind die mangelhaften Strukturen, die es immer schwerer bis unmöglich machen, die notwendigen Informationen für einen bestimmten Abstraktionslevel wieder mit vernünftigem Aufwand und vernünftiger Zuverlässigkeit aus der Datenbank herauszulesen.

+1 Du sprichst mir da völlig aus dem Herzen.

Weil wir hier auch bei persönlichen Erfahrungen sind: An Dir habe ich mich ja im Laufe der Projektjahre immer wieder abgearbeitet: Es war Deine Wanderreitkarte, die mich überhaupt darauf gebracht hat, bei Openstreetmap mitzumachen. Die Karte hat ein eigenes Forum und ein gutes Programm um selbst Karten zu erstellen. Dann gab es da das Wiki Reiten (und unlogischerweise eine zweite Seite DE:Riding). Meine Erwartung war total klar, dass das zusammenhängt. Ganz schnell merkte ich "Löcher" und dachte dann halt, dass auf den State of the maps oder sowas eine manchmal etwas chaotische Arbeitsgruppe tagt - und ich hab mich ja immer wieder mit den Versuchen, zumindest mal die beiden Wikiseiten zusammenzuführen (ich wollte sie auf schwedisch übersetzen) an Dich gewand wie an einen Sprecher eines Arbeitskreises und war zwischenzeitlich mal recht frustriert dass Openstreetmap so wahnsinnig bürokratische Strukturen hat. Bis ich verstanden hab, dass das wirklich rein garnichts miteinander zu tun hat und Du diese Wikibereiche sogar als komisch betrachtest und wenn ichs richtig verstanden hab, hoffst, dass es nie in dieser Form relevant wird, vergingen mehr als 3 Jahre.

Wenn Du von Struktur sprichst, dann denke ich manchmal, dass die garnicht so schlecht wäre: Ein Interessensgebiet hat meistens einen Hauptauswerter (und vielleicht noch Nebenauswerter), die organisieren ja sowieso eine sinnvolle Interpretation des vorhandenen taggings (oder auch die Entscheidungen, was wegzulassen). Ich hab irgendwie nie verstanden, warum es eine Wikiseite zum Thema Reiten geben soll, die ohne das es eine Empfehlungen wiedergibt hinter denen Du nicht stehst und sogar sinnlos findest ohne das es mir jemals gelungen ist, jemanden zu finden, der die Empfehlungen wie sie im Wiki stehen für sinnvoll hält und erklären könnte 🙂
Schaffen wir Zusammenhänge

-- snip --

1. Wo hab ich denn gesagt, dass man dran teilnehmen muss? Aber wenn man als Normalmapper kaum mitbekommt, welche Fragen aktuell diskutiert werden, kommt man halt zu Proposals, bei denen am Ende mit 17:2 Stimmen oder so ein etabliertes Schema umgeworfen werden soll - dass das am Ende keine Autorität hat, braucht keinen Wundern. Insofern: Leute aktiv dazu motivieren, eine Meinung zu einem dann verbindlichen Ergebnis abzugeben. Kein Zwang.
2. Weil a) viele Mapper sicher nicht damit einverstanden wären, wenn Entscheidungen nur von einer kleinen Gruppe getroffen werden und b) die Interessen der Auswerter (und insb. derer, die Karten anbieten, im Vergleich zu verschiedenen anderen Anwendungszwecken) ja nicht die einzigen sind. Deshalb informell - dann kann Abstimmung stattfinden und vieles einheitlich gehandhabt werden sowie Meinungen frühzeitig eingebracht werden. Aber keiner (außer der Gemeinschaft als Ganzes - bzw. der an der jeweiligen Fragestellung interessierten Teile der Gemeinschaft) bekommt das Recht, zu beschließen, dass XY jetzt nicht (mehr) zu mappen ist.
3. Und der momentane status quo ... funktioniert nicht. Deshalb ist das ja ein Vorschlag für die Zukunft. Nationale oder regionale Alleingänge lassen sich hinterher nicht mehr zusammenfassen - wenn in Deutschland tausende Mapper verinnerlicht haben, dass highway=path ein Trampelpfad ist während tausende britische Mapper jeden echten Fuß-, Rad- oder Reitweg zum hw=path gemacht haben, kommt hinterher keine Vereinheitlichung mehr zustande. Außerdem entsteht so ein Henne-Ei Problem. Wird ein Proposal zunächst üblicherweise auf Englisch veröffentlicht und angenommen, gibt es ja noch keine regionale Positionierung, wie man das handhaben möchte. Man muss also zunächst der englischen Version folgen und würde erst im Nachhinein dann eine regionale Abwandlung davon festlegen, die der ursprünglichen Intention vielleicht vollständig zuwider läuft. Siehe eben hw=path. Außerdem führen regionale, unterschiedliche "Goldstandards" (ich wäre dir im Übrigen sehr verbunden, wenn du das Wort Standard korrekt schreiben würdest, danke 🙂) nur zu noch mehr Problemen für die Auswertung, nicht umsonst sind wir zu dem Schluss gekommen, dass man maxspeed=50 source:maxspeed=DE:urban taggen sollte und nicht maxspeed=DE:urban - sonst hat der Auswerter es im Grenzgebiet enorm schwer. Nein, vernüftig funktionieren kann nur ein von vornherein internationaler Standard, zu dem dann nur regionale Besonderheiten dazudefiniert werden (als Beispiel admin_level: International gültige Definition, dann Zuordnung zu deutschen Verwaltungsgliederungen - wie sollte das denn aussehen, wenn erstmal jedes Land sich seine eigenen Tags ausdenkt, um sowas darzustellen? Dann würden wir in Deutschland heute vllt. federal_state=yes, die Amerikaner administrativ=state und die Franzosen möglicherweise level:administration=3 taggen. Wo ist denn da der Sinn?).

chris66 wrote:

Im Wiki steht bis heute:

Einzelner oder signifikanter Baum [1]

Im deutschen Wiki. Im Englischenwurde es 2010 auf "A single tree, sometimes lone or significant." geändert.

Aber stimmt, nach dem deutschen Wiki hätte es die ganzen Blumenkübelimporte und Spaß-jeder-Baum-im-Wald-Einzeln-Aktionen niemals geben dürfen.

Daß sich die verschiedenen Sprachversionen im Wiki widersprechen hatte ich auf meiner Liste von Problemen noch vergessen. :-)

bye, Nop

Skinfaxi wrote:

Ich finde es völlig in Ordnung, wenn genau umgekehrt vorgegangen wird: Die lokalen Chapter machen ein Wiki, dass für das abgegrenzte Gebiet verbindlich ist. Hier können dann aussagekräftige, lokal relevante Beispiele und Fotos genommen werden und der landesspezifische "Goldstandart" definiert werden. Und danach wird das so weit es geht international synkronisiert - am besten von der Arbeitsgruppe, die Du unter 2 beschrieben hast. Das wird wesentlich konkreter und begreifbarer - und ist im Moment sowie defacto der Status quo.

Das ist aber etwas missverständlich. Du meinst damit sicher nicht, dass irgendein lokales Chapter beschließen könnte, dass es künftig in seinem Gebiet (sagen wir, nur als Beispiel, auf den Philippinen) mit highway=motorway eine Autowerkstatt, mit natural=water eine Bar und mit natural=peak eine Telefonzelle bezeichnen möchte und dass dann ab sofort jedermann im Bereich der Philippinen dieses Tagging benutzen muss? Dann müssten ja die Auswerter für jedes von einem lokalen Chapter beherrschte Gebiet eigene Auswertungsregeln benutzen. Hm, OSM mag bisher chaotisch sein, aber auf diese Weise würde es noch viel viel chaotischer. Ich bin sicher, dass Du das nicht gemeint hast, oder? 😉

Was meine Nachfrage mit dem übertriebenen Beispiel sagen soll: Ein und dasselbe Tag sollte mMn so weit wie irgend möglich überall dasselbe bedeuten; wir sollten die – heute unzweifelhaft bestehenden – Unterschiede eher verringern als vergrößern und nichts tun, was zu einer weiteren „Lokalisierung“ von Tags führen kann. Daher sollten lokale Chapter möglichst wenig definitorische Macht haben und sich höchstens um besondere regional wichtige Tags kümmern.

Harald Hartmann wrote:

seawolff wrote:

Selbst beim Straßen- und Wegenetz, dass man als Kernkompetenz von OSM vermuten würde, gibt es abhängig vom letzten Bearbeiter deutliche Unterschiede. Einige Mapper entscheiden streng nach amtlicher Klassifizierung, andere nach gefühlter Verkehrsbedeutung und manche haben weitere Kriterien.

Hmm, da sieht man dann, wer das Wiki gelesen hat und wer nicht. Also ich bin jetzt von DE:highway zu DE:Highways zu Attributierung von Straße in Deutschland gesprungen, und konnte nicht wirklich Widersprüche finden, sondern eigentlich immer den (teils fetten) Hinweis, dass man sich eben NICHT nach amtlicher Klassifizierung richten soll ... was vermutlich aber gerade den Gesetzes-Verordnungs-Reitern trotz dieses Wissens schwer fällt.

Ich habe den Eindruck, dass die Mehrzahl der Mapper nur die offizielle Klassifizierung als Kriterium nutzt.
Hier ist ein schönes Beispiel, dass die Regeln nicht einmal lokal konsistent sind.
Die Anleger am West- und Ostufer haben offensichtlich die gleiche Verkehrsbedeutung, sind aber einmal als "service" mit "service=driveway" und einmal als "tertiary" erfasst.

Bei vielen Objekten fehlen Tags um abzuschätzen, ob sie lokal, regional oder überregional relevant sind (Bäume, Flugplätze, Kanäle, Attraktionen).

Subjektives Empfinden, also ungeeignet für OSM ... ich erinnere mich da wieder an place:importance 🤣

Man könnte Kriterien definieren (Kronendurchmesser und lokale Dominanz bei Bäumen; Passagierzahl und Zahl der Landungen bei Flugplätzen; Frachtmenge und Zahl der Schiffspassagen bei Kanälen; ...) oder einfach eine relative Relevanz abschätzen (Objekt gehört zu den 30 % / 10% / 3% / 1% wichtigsten mit gleichem Haupttag).
Viele Anwendungen würden auch von einer ungefähren Relevanzangabe profitieren.

Aber aus OSM ist leider keine universelle Geodatenbank geworden, mit der man Fragen nach der Anzahl, Gesamtlänge oder Fläche von bestimmten Objektklassen in einem Gebiet beantworten kann.

Nicht? Beispiel: ich hole mir aus dem Thüringen Extrakt der Geofabrik mit wambachers-boundariy-poly für Schleusegrund ein bestimmtes Gebiet, jage diese Daten durch osmium_road_length und erhalte separiert für alle highway die Länge...

Du erhältst eine Tabelle für die OSM-Tags, aber Aussagen über die reale Welt sind schwierig.
Die Verteilung hängt stark davon ab, nach welchen Kriterien die Mapper gearbeitet haben, ob sie straßenbegleitende Wege als eigenen way oder eher als Attribut (oder doppelt) erfasst haben und ob die Friedhofswege als "service", "track", "path", "footway" oder noch gar nicht in OSM stehen.
Bei den Autobahnen dürfte der Wert recht exakt sein, aber was sagt die Länge von "tertiary"?

Oder die Anzahl der Bänke mit Rückenlehne in Schleusegrund ist doch z.b. mit Overpass Turbo ohne weiteres möglich... (klar, man muss sich halt in eine "Abfragesprache" einarbeiten ... wofür es aber eine mehr als ausreichende Dokumentation sowie vielen Beispiel gibt)

Die Abfragesprache ist nicht das Problem, sondern die Qualität der Daten.
Für Schleusegrund mag die Zahl stimmen (was außer dir vermutlich niemand weiß), aber in anderen Orten ist nur ein sehr kleiner Teil der Bänke erfasst und die Mehrzahl davon hat keine Information zu Rückenlehnen.
Die Abschätzung über die Einwohnerzahl mit einer mittleren Dichte der Bänke pro 1000 Einwohner dürfte meist zuverlässiger sein als OSM.
Bei anderen Tags hat OSM zu viele falsch positive Treffer.
Die Zahl der Tischlereien oder anderer Handwerksbetriebe könnte man allenfalls über Gebäudenamen in Industrie- und Gewerbegebieten ermitteln.

Chrysopras wrote:

Was meine Nachfrage mit dem übertriebenen Beispiel sagen soll: Ein und dasselbe Tag sollte mMn so weit wie irgend möglich überall dasselbe bedeuten; wir sollten die – heute unzweifelhaft bestehenden – Unterschiede eher verringern als vergrößern und nichts tun, was zu einer weiteren „Lokalisierung“ von Tags führen kann. Daher sollten lokale Chapter möglichst wenig definitorische Macht haben und sich höchstens um besondere regional wichtige Tags kümmern.

Ich meine wir bilden eine Realität als Karte ab, auf Der wir uns orientieren. Die Informationen an sich sind ziemlich sinnlos, spannend wird das ganze durch den Kontext und Zusammenhang.

Und dieser Zusammenhang erklärt sich bei recht vielen Dingen im Vergleich und der lokalen Funktion.

Schon bei Deinem Beispiel mit der Autowerkstatt wird das deutlich: In Deutschland geht es beispielsweise eine Untergrenze angelehnt an nationale Standarts: Man braucht einen Meister und noch irgendwas. In Schweden ist das völlig anders, aber auch hier gibt es einfache Möglichkeit, Werkstätten von Schrottplätzen und Autoselbsthilfe etc abzugrenzen.

Daher meine ich, dass die Chapter die tags definieren und meinetwegen Subtags dazu machen können. Den die Abstraktionsleistung findet in einem kulturellen und räumlichen Kontext Statt.

Es entfernen zB immer wieder Gastmapper die Behördentags an den Büros der schwedischen Kirche. Wer die Geschichte und Stellung der Kirche nicht Kennt, kann sowas aber nicht beurteilen und weis garnicht was mit einrichtung behörde operator Kirche ausgedrückt werden Soll.

Und das ist doch einfach international nicht konsistent sondern national - und daher kannst du auch keine einheitliche aufladung des taggings erreichen.

Chrysopras wrote:

[...] Ein und dasselbe Tag sollte mMn so weit wie irgend möglich überall dasselbe bedeuten; wir sollten die – heute unzweifelhaft bestehenden – Unterschiede eher verringern als vergrößern und nichts tun, was zu einer weiteren „Lokalisierung“ von Tags führen kann. [...]

+1!

Skinfaxi wrote:

An dem Versuch, eine weltübergreifenden Standart zu schaffen, verheben wir uns doch - und keiner blickt mehr durch. Ich finde es völlig in Ordnung, wenn genau umgekehrt vorgegangen wird: Die lokalen Chapter machen ein Wiki, dass für das abgegrenzte Gebiet verbindlich ist. Hier können dann aussagekräftige, lokal relevante Beispiele und Fotos genommen werden und der landesspezifische "Goldstandart" definiert werden. Und danach wird das so weit es geht international synkronisiert - am besten von der Arbeitsgruppe, die Du unter 2 beschrieben hast. Das wird wesentlich konkreter und begreifbarer - und ist im Moment sowie defacto der Status quo.

Aber wenn weiter jede lokale Gruppe so mappt, wie es ihr passt, wird das Chaos noch größer. Zumal oft auch gar nicht klar ist, was wo gerade wie gemacht wird.

Für bestimmte Dinge müssen Standards her. Ok, das Beispiel mit der Kirche in Schweden zeigt natürlich, dass es niemals möglich sein wird, alles zu vereinheitlichen, aber in bestimmten Bereichen geht das durchaus.

Z.B. sollte für mich immer im name-Tag immer der Name in der/den Amtssprachen der Region. Das griechischsprachige Zypern sollte daher nicht primär auf Englisch gemappt werden. Genauso sollten die UAE auf Arabisch und nicht auf Englisch gemappt werden.

Es sollte meiner Meinung nach auch feste Regeln geben, ob z.b. Gartenzäune, Bäume in Gärten, etc gemappt werden sollen, und falls nein sollte man entsprechende Objekte auch wieder löschen.

Gppes wrote:

Chrysopras wrote:

[...] Ein und dasselbe Tag sollte mMn so weit wie irgend möglich überall dasselbe bedeuten; wir sollten die – heute unzweifelhaft bestehenden – Unterschiede eher verringern als vergrößern und nichts tun, was zu einer weiteren „Lokalisierung“ von Tags führen kann. [...]

+1!

Ich hab ja überhaupt nix dagegen, dass es möglichst einheitlich ist. Ich sage nur auf der Basis meiner eigenen Mappingerfahrung, dass Du unmöglich die Kompelxität die es in der Wirklichkeit gibt, abbilden kannst. Ich meine es hat seinen Sinn, dass der ADAC beispielsweise Merkblätter herausgibt, was man als Autofahrer in Schweden beachten muss - und in anderen Ländern ist das natürlich noch schlimmer.

ich füttere nochmal ein paar Beispiele:

- in Deutschland und ziemlich weiten Teilen Europas ist eine Fernverkehrsstrasse, die mitten über einen See läuft fast immer falsch. In Schweden gibt es das - ganz offizielle Eisstrassen. Im Moment werden die oft gutgemeint "korrigiert", parallel zu Fährlinien gesetzt oder von vielen Auswertern komplett weggelassen. Bevor ich jetzt die Erwartung hab, dass alle Mapper sich mit dem "da ist was besonderes" auseinandersetzen, erscheint es mir sinnvoll, wenn ein Wiki nur die relevanten Fragen beschreibt und dabei auch geografische Gliederungen verwendet. -- edit--- (Nebenspur aber schaut Euch mal Objekt http://www.openstreetmap.org/way/110280212 dessen Darstellung und History an 🙂)

- genauso gibt es Konsitensbemühungen was die Klassifikation von Strassen angeht. Egal ob "trunks" oder "Kreisstrasse" (die oft unasphaltiert sind) - hier sind es Kompromisse, die in Diskussionen gefunden wurden und verschiedene Aspekte einbeziehen. Was in Deutschland mit 98% Wahrscheinlichkeit ein Fehler ist (eine unasphaltierte Fernstrasse) ist hier ganz normal. Und wenn wir schon zwischen sich zwei kulturell doch so nahe stehenden Ländern so viele Inkompatibilitäten entdecken, möchte ich garnicht wissen, wie das mit dem Osten aussieht. Und ich finde nicht, dass es legitim sein sollte, in solche Prozesse die eine Ganzheit für ein Land im Blick haben, einzugreifen und die Arbeit zu verstören weil man den Blick auf eine einzelne Strasse richtet. (die ist besser ausgebaut als das was daneben als trunk markiert ist, also klasse ich die Strasse herauf).

Das dumme daran ist ja: Diejenigen die Versuchen systematisch und Zusammenhänge konstruierend zu arbeiten, müssen notwendigerweise akzeptieren, dass es in irgendeinem Einzelfall mal nicht ganz passt - denn egal wie man es macht, es wird immer Kompromisse geben. Haben nun die "Einzelfalldenker" die gleiche Legimität wie Zusammenhanghersteller, entsteht nie was konsitentes.

Ich finde es wesentlich wichtiger, dass die Karte in einem mölgichst grossen Umkreis in sich konsitent ist als dass ich die potentielle Chance habe Strassen in Indien mit Strassen in Schweden vergleichen kann.. Je grösser der Bezugsrahmen ist, desto kleiner (und unschärfer) wird der "gemeinsame Nenner".

Und wo nötigLändergrenzen zur Gliederung und Abgrenzung des Taggings zu verwenden erzeugt vermutlich wesentlich weniger Chaos als der Versuch, weltweit alle Spezialfälle ohne Gliederung zu erfassen.

Skinfaxi wrote:

- in Deutschland und ziemlich weiten Teilen Europas ist eine Fernverkehrsstrasse, die mitten über einen See läuft fast immer falsch.[...]

- genauso gibt es Konsitensbemühungen was die Klassifikation von Strassen angeht. [...]

[...] die Karte in einem mölgichst grossen Umkreis in sich konsitent ist als dass ich die potentielle Chance habe Strassen in Indien mit Strassen in Schweden vergleichen [...]

Ich fasse mein +1 kurz in Worte: "Man soll moeglichst das gemeinsame, universelle Konzept suchen, lokale Details ergeben sich ohnehin durch jeden einzelnen Mapper".

Die "Eisstrasse" wuerde ich, egal wo es sowas gibt, immer gleich taggen. Wieso sollte man das in Schweden, Groenland oder sonstwo anders machen? So wie es jetzt getaggt ist, gefaellt es mir gar nicht schlecht. Leider kann es passieren, dass ortsfremde Mapper Daten "kaputt" machen. Das kommt ueberall in allen erdenklichen Variationen vor. Damit muss man leider leben. Ein perfektes Taggingschema, das so etwas verhindert, gibt es aus meiner Sicht nicht. Was soll man noch tun ausser eine Note dran haengen und ein conditional tag setzen?

Die Klassifikation von Strassen ist ja ein sehr pikantes Thema. Bei unserem Stammtisch in der Obersteiermark gibt es zu einigen Strassen drei Meinungen. Wir haben uns teilweise auf ein Schema geeinigt, es ging z.B. um die Nutzung von highway=track vs. highway=unclassified, wenn die Strassenqualitaet schlecht ist (z.B. Schotterstrasse). Hier im Forum hatte ich damals angefragt: Der Konsens war, dass die Art und Intensitaet der Nutzung fuer die Klassifizierung eine Rolle spielt. Das ist doch ein universelles Konzept! Und ich gehe davon aus, dass ein Router hoehere Strassenklassen eher bevorzugt als niedrigere. Dass die Qualitaet der Strassenoberflaeche von Land zu Land und Bezirk zu Bezirk unterschiedlich ist, macht dann ja gar nichts aus!?

Ich glaube nicht, dass wir grundsätzlich wirklich anderer Meinung sind. Das meiste scheint eher ein Missverständnis zu sein.
Jedenfalls ist für mich klar:
Tagdefinitionen müssen erstmal von der internationalen (d.h. englischen) Ebene ausgehen. Die konkrete Auslegung (in Schweden mögen hw=primary über Seen sinnvoll sein, in Deutschland vllt. nicht; in Deutschland sollten Bundesstraßen evtl. immer mindestens hw=secondary sein; in Wasweißichistan gibt es keine Trampelpfade, weil Trampeln verboten ist) bleibt den lokalen Gruppen überlassen, muss aber konsistent dazu bleiben (also eben kein "Hier verwenden wir landuse=farm, obwohl das im Rest der Welt abgeschafft wurde" oder "Bei uns schließt bicycle=designated auch horse=yes mit ein"). Und wenn etwas benötigt wird, das es bis jetzt (anscheinend) noch nicht gibt, sollte man auch das auf internationale Ebene einbringen, damit eben nicht schwedische Eisstraßen am Ende anders getaggt sind als kanadische oder russische.

Und das Problem ist ja am Ende nicht die Vergleichbarkeit zwischen Indien und Schweden (dass ich mir im einen unter einer Hauptverkehrsstraße was anderes vorstellen muss als im anderen, ist ja völlig in Ordnung, deshalb können die gleichen Tags hier für durchaus unterschiedliche Straßen stehen). Das Problem ist 1. die Vergleichbarkeit zwischen Frankfurt (Oder) und Słubice oder, wenn ich Pech habe, zwischen Ludwigshafen und Mannheim und 2. die Auswertbarkeit über große Gebiete überhaupt (der Renderer der Hauptkarte auf osm.org muss nunmal Hauptstraßen aus Schweden und aus Indien abdecken, und das geht nicht, wenn beide völlig unterschiedliche Tags nutzen).

Als jemand, der erst seit 2 Jahren dabei ist, fällt mir auf, auch in dieser "Grundsatzdiskussion" gilt grundsätzlich:

Unser täglich Baumbashing gib uns heute ...

Mir, als bekennender Baummapper, ist auch nachdem ich Beuys "7000 Eichen" gemappt habe, schleierhaft, wen, wo und warum diese Bäume stören könnten. Fast wäre ich froh, wenn die "Standardkarte" (die einzige mir bekannte Karte, die natural=tree ohne denotation/name=x überhaupt darstellt) auf Baumdarstellungen ganz verzichten würde, damit ich mir dieses ritualisierte Gejammere nicht mehr durchlesen muss. Möge mich jemand aufklären, wo liegt denn das große Baum-Problem?

Anmerkung 1: OSM ist weder Karte NOCH Goedatenbank, sondern eine
https://de.wikipedia.org/wiki/Soziale_Plastik

Anmerkung 2: Nebenbei kommt mir einiges des hier geäußerten Kulturpessimismus ("früher war alles besser - heute wird alles immer schlimmer"), seit gefühlten 100 Jahren bekannt vor, aus einer anderen sozialen Plastik - der Wikipedia

@Jo Cassel du musst den Thread eher als "AfO" (Alternative für OSM) Sammelthread sehen, alle die sich irgendwie mal nicht durchsetzen konnten kehren jetzt ihre alten (zum Teil uralten) Kränkungen etc aus und hoffen darauf hier ein geneigtes Publikum zu finden.

Die Bandbreite der Klagen ist gross von technischen Missverständnissen (nein das OSM Taggingsystem war noch nie wirklich hierarchisch) bis zum Wunsch nach Wikipedia(-DE) ähnlichen polizeilichen Massnahmen. Wie bei der AfD, haben aber die Vorstellungen wenig miteinander zu tun.

SimonPoole wrote:

[...] Sammelthread [...] alle die sich irgendwie mal nicht durchsetzen konnten [...] Kränkungen [...] hoffen [...] geneigtes Publikum zu finden.

Na, ich gehe davon aus, dass in Deinem Beitrag eine ordentliche Portion Ironie dabei ist und setze hier noch eines drauf:

Du hast also von allen Mappern gesprochen, die mehr als ein, zwei Edits vorgenommen haben?

-D

Ganz ehrlich: Diese soziale Komponente von OSM, an etwas die Freude zu behalten, obwohl es (schon direkt neben der Haustuere) so viele kontroverse Meinungen gibt, ist fuer mich ein schoener und interessanter Punkt bei OSM bleiben zu wollen!

Luxusprobleme

Sooo schlecht finde ich das Erreichte übrigens nicht.

Ich denke wir sind ziemlich nah am Optimum was mit einer Crowd (die größtenteils aus Geo-Laien besteht) möglich ist.

😉

Edit: Typo

chris66 wrote:

mit einer Croud

Situs vilate inisse tabernit.
Crowd oder Cloud 🙂

--ks

Kraut?

Hallo,

Gppes wrote:

SimonPoole wrote:

@Jo Cassel du musst den Thread eher als "AfO" (Alternative für OSM) Sammelthread sehen, alle die sich irgendwie mal nicht durchsetzen konnten kehren jetzt ihre alten (zum Teil uralten) Kränkungen etc aus und hoffen darauf hier ein geneigtes Publikum zu finden.

Die Bandbreite der Klagen ist gross von technischen Missverständnissen (nein das OSM Taggingsystem war noch nie wirklich hierarchisch) bis zum Wunsch nach Wikipedia(-DE) ähnlichen polizeilichen Massnahmen. Wie bei der AfD, haben aber die Vorstellungen wenig miteinander zu tun.

Na, ich gehe davon aus, dass in Deinem Beitrag eine ordentliche Portion Ironie dabei ist und setze hier noch eines drauf:

Da steckt schon ein wahrer Kern dahinter. Große Teile der Diskussion in diesem Thread sind persönliche Meinungen basierend auf Pseudofakten, denen es an Belegen mangelt.

seawolff wrote:

Die Taggingqualität hat sich leider über die Jahre kaum verbessert und zum Teil sogar abgenommen.
Viele Tags sind im Wiki immer noch inhaltlich schlecht definiert.
Teilweise gibt es im Wiki Widersprüche zwischen verschiedenen Versionen, Unterseiten oder Sprachen eines Tags.

Dafür möchte ich um ein paar Belege bitten. Sonst ist das für mich wie ein Teil dieses Threads einfach faktenarmes Stammtischgeschwätz.

seawolff wrote:

Manche Tags wurden im Laufe der Zeit so verwässert., dass sie nicht mehr im ursprünglichen Sinn auswertbar sind.
So wird mache Naturbadestelle zum "water_park", einige Bänke im Halbrund zum "theatre" und ein Luftballonverkauf zur "attraction".

Belege bitte! Liegt es vielleicht nicht an der Unerfahrenheit der Mapper gepaart mit dem verwendeten Editor?

seawolff wrote:

Mancherorts wird jedes Universitätsgebäude zur "university", jeder Saal eines Gebäudes zum "theatre" oder jede Parkreihe zu einem Parkplatz.

seawolff wrote:

An vielen Stellen sind relevante Information nicht strukturiert erfasst, sondern nur im Namen abgelegt
(z.B. "building=yes" mit Namen "Scheune aus Musterdorf (1760)", "ABC-Versicherung Hauptsitz", "Tischlerei Müller GmbH", "Lager" oder "Tickets").

Weißt du, du erinnerst mich an eine Gruppe alter Leute, die in der Wirtschaft um den Tisch sitzen und der eine zum andern sagt "Ach, die Politiker, überall stecken sie das Geld rein, bloß in die Straßen nicht. Lauter Schlaglöcher. […]" Anstatt aber selber die Dinge zu ändern und sich zu engagieren, machen sie nichts. Genau so ist das hier auch!

Ihr habt alle die Chance mitzuhelfen, dass OSM besser wird. Wenn ihr aber, statt bei der Verbesserung der Editoren, lieber den Ärger in euch hineinfresst, kann ich euch leider nicht helfen.

seawolff wrote:

Die Trennung von Landnutzung und Landbedeckung wurde oft diskutiert (und würde manche Probleme lösen), wurde aber kaum umgesetzt.

Es fehlen weitgehend Datenstrukturen, die zusammengehörige Objekte miteinander verbinden.
Die Linienbündelung, die zu Beginn meiner OSM Zeit eifrig diskutiert wurde, bleibt ungelöst.
Teilweise wurden zusammengehörige Objekte (z.B. Bushaltestellen und Unterstand) später in zwei unverbundene POIs geteilt
Durch solches Mikromapping wird zwar die geometische Genauigkeit verbessert, aber oft verliert man dadurch inhaltliche Zusammenhänge,

Solche Verbindungsstrukturen braucht man nicht. Räumliche Nähe und Ähnlichkeiten zwischen den Tags genügen. Manuell ergänzte Verbindungsstrukturen (z.B. AssociatedStreet-Relation, Stop-Area-Relation usw.) können nie vollständig sein, das sie von Sammelrelations-artiger Natur sind. Durch clever formulierte SQL-Abfragen oder andere Verfahren kann man jedoch die Information trotzdem erhalten.

seawolff wrote:

Ich sehe auch kaum Bemühungen, die OSM-Daten mit externen Daten interoperabel zu machen.
Die Buslinien, deren Erfassung wegen der komplizierten Datenstrukturen ohnehin kaum vorankommt, würden erst durch die Verknüpfung mit Fahrplandaten einen größeren Nutzen gewinnen.

Wo sollte OSM denn interoperabler werden? Beispiele bitte!

seawolff wrote:

Bei vielen Objekten fehlen Tags um abzuschätzen, ob sie lokal, regional oder überregional relevant sind (Bäume, Flugplätze, Kanäle, Attraktionen).

Es sind im Laufe der Jahre sehr viele Taggingvorschläge dazugekommen.
Meist gibt es keine Entscheidungen für ein Datenmodell, so dass mehrere Varianten nebeneinander existieren.
Ich habe in manchen Bereichen die Übersicht verloren.

Nur für einige Spezialthemen (Eisenbahn, Stromnetz, Seezeichen, Grenzen) gibt es gut definierte Taggingregeln und im Ergebnis auch eine weitgehend einheitliche Datenstruktur.

Wo hast du denn die Übersicht verloren?

Harald Hartmann wrote:

seawolff wrote:

Bei vielen Objekten fehlen Tags um abzuschätzen, ob sie lokal, regional oder überregional relevant sind (Bäume, Flugplätze, Kanäle, Attraktionen).

Subjektives Empfinden, also ungeeignet für OSM ... ich erinnere mich da wieder an place:importance 🤣

Dem kann ich nur zustimmen. Ich war bis vor Kurzem auch noch ein Freund von einem Importance-Tag für Bahnhöfe, möchte die Idee aber erst weiter verfolgen, wenn es mir nicht gelingt, ein vergleichbares Ergebnis automatisiert zu erzeugen.

Harald Hartmann wrote:

seawolff wrote:

Aber aus OSM ist leider keine universelle Geodatenbank geworden, mit der man Fragen nach der Anzahl, Gesamtlänge oder Fläche von bestimmten Objektklassen in einem Gebiet beantworten kann.

Nicht? Beispiel: ich hole mir aus dem Thüringen Extrakt der Geofabrik mit wambachers-boundariy-poly für Schleusegrund ein bestimmtes Gebiet, jage diese Daten durch osmium_road_length und erhalte separiert für alle highway die Länge...
Oder die Anzahl der Bänke mit Rückenlehne in Schleusegrund ist doch z.b. mit Overpass Turbo ohne weiteres möglich... (klar, man muss sich halt in eine "Abfragesprache" einarbeiten ... wofür es aber eine mehr als ausreichende Dokumentation sowie vielen Beispiel gibt)

Wie Harald schon aufgezeigt hat, ist diese Behauptung von dir falsch. (Und wenn einem C++ und Osmium nicht zusagen, kann man es auch mit einer PostGIS-Datenbank machen, nur dass es eben langsamer ist)

Die Datenbank der OSM-API hat nicht das Ziel, solche Abfragen zu ermöglichen. OSM stellt Daten bereit, die Auswertung ist Sache der Nutzer. Dieses modulare Ökosystem-Konzept ist das, was ich an OSM so sehr schätze.

seawolff wrote:

Einige Jahre habe ich zunächst in der Mailingliste und später im Forum mitdiskutiert.
Viele Diskussionen endeten ohne Ergebnis und selbst bei einem Konsens war keine Entscheidung dauerhaft oder verbindlich.
Ich hatte kurze Zeit die Hoffnung, das sich über Harald Hartmanns Umfrageplattform zumindest ein zählbares Meinungsbild der Aktiven gewinnen lässt, aber die Plattform wurde bald wieder eingestellt.
Ohne die Möglichkeit verbindliche Ergebnisse zu erzielen, ist mein Interesse an den Diskussionsforen nach und nach eingeschlafen.

Es ist schade, dass er die Umfrageplattform nicht mehr betreibt, aber der Quellcode ist auf Github (bloß leider ohne Lizenzangabe und daher unfrei).

toc-rox wrote:

Was mir so spontan einfällt ...
- Es fehlt ein konkreter Tagging-Gold-Standard. Basis müßten dabei die Vorschläge der Community sein. Die finale Festlegung und Dokumentation müßte aber von einer "offiziellen" OSM-Arbeitsgruppe erfolgen.

Das sind drei Themen, bei denen du dich nicht durchsetzen konntest und das ist gut so! OSM ist der Gegenentwurf zu einem festen Datenbankschema. Unsere flexibles Tagging hat zwar auch Nachteile, aber die Datennutzer tun durch ihre Selektivität einen Normierungszwang ausüben. Je bedeutender ein Datennutzer in einem Themenfeld ist, desto größer ist sein Einfluss.

toc-rox wrote:

- Beschränkung der DB-Inhalte. Hier sollte man überlegen, ob man wirklich jedes Objekt in der Datenbank haben möchte. Insgesamt besteht ein gewisse Gefahr, daß man in der Datenflut ertrinkt. Weniger ist oft mehr.

Vor neun Jahren war es noch unüblich das Gebäude gemappt wurden, die Luftbilder nicht verfügbar waren. Gebäude, die gemappt waren, waren in irgendeiner Art und Weise richtig. Du musst dich damit anfreunden, dass OSM sich ändert. Was vor Ort ist, wird erfasst werden. Wenn dir das nicht passt, musst du dein eigenes Projekt gründen. Die Lizenz lässt das zu.

Viele Grüße

Michael

@Nakaner: -1 ... deinen Post finde ich seiner Gesamtheit reichlich arrogant und überheblich. So kommen wir in der Sache kaum (nicht) weiter.

Gruß Klaus

Ich sehe den Beitrag von Nakaner differenziert. Es ist schon richtig zu hinterfragen, was wir besser machen können. Haben wir keine konkrete Beispiele dafür was jemand als Verschlechterung seht, so können wir auch nicht reagieren.
Mich würde eine Liste der Themen die kontrovers sind, sehr interessieren.

Auch eine globale Umfrage wäre sehr interessant. Vielleicht können wir Harald Hartmanns Umfrageplattform irgendwie wiederbeleben.

Viele Grüße,
Marek

Wie toc-rox schon sagte, der Thread driftet mir zu sehr weg vom sachlichen.

Ich glaube, dass Seawolff schon etliches geleistet hat und sich sicher nicht wie ein alter Mann am politischen Stammtisch verhält. Er hat wohl auch schon eingies an Beispielen genannt, wer dann immer noch mit Belegen kommt, wenn einer sagt, mir gefällt nicht wie OSM läuft und sich entwickelt hat, weil ich mehr Probleme als Nutzen davon hab, der hat die letzten paar Seiten nicht verstehen wollen.

Das scheint auch das Problem in der Community zu sein, zu wenig Verständnis für den Standpunkt des anderen. Das führt wiederum nur dazu, dass sehr viele der "Nörgler" (oder einfach Leute mir Erfahrung, wenn man sich deren Profile mal anschaut?!?) sich aus der Community einfach zurückgezogen haben und resignieren.

Es läuft wie so oft, es wird viel diskutiert, kein Konsens erzeugt, Vorschläge ins negative gezogen und wer gerade sich noch beteilligen wollte verliert mehr und mehr die Lust an der Community.

Manchmal muss man einfach etwas umsetzen, ohne Konsens, einfach nur, weil es sinnvoll ist, siehe z.B. landuse=farm.

Ich klinke mich ebenfalls wieder aus. Viel Spaß noch.

Hi Seawolf,

lass dich nicht ärgern 😉 Bei mir ist es fast ähnlich.. bin ja a schon eine Zeit hier dabei.

Über die Jahr hab ich mal dies gemappt dann mal das. Unser Kirche im Ort gibts auch in 3D mittlerweile... was nicht alles geht 😎

Aber immer mit der Prämisse worin in Sinn darin sah, nutzen, oder nicht zu aufwändig war bzw. cool finde. Ganz am Anfang war es für mich nicht einmal wichtig Hausnummern zu Mappen... kam dann erst später... (Aber für eine einzelne Hausnummer, gehe ich heute noch immer nicht extra vor die Tür. Komm das Leben muss doch auch noch Spannend bleiben 😉 )

Was ich für Deutschland sagen kann ist das die Qualität der Daten sehr schwankt.. nicht vom Tagging, so genau will ich nicht schauen, sondern vom Grad der Erfassung.. von Städten wo jeder Grashalm erfasst ist.. bis zu Orten wo nur der Ortsname erfasst ist (wenn es gut läuft) und die Durchgangsstraße aber sonst nix.. kein landuse=, kein building=, kein gar nichts 🤔 . Da würde man sich manchmal wünschen ein paar Grashalmerfasser würde dort mal mit anpacken.

Mit dem Fuß-Fahrradmapping Detail-Wahnsinn kommt dann schon so ein Mist dabei raus.. habe ich heute erst korrigiert. In diesem Fall wird es dem Fahrradfahrer schwer gemacht die Kreuzung zu überqueren.
http://www.openstreetmap.org/directions … 1/11.63988

Diskussionen finde ich auch meist recht fruchtlos, oft Zeitverschwendung eigentlich schade 😐 , aber es gibt auch viele Interessen und es gibt nicht DIE Karte.. sondern für alle möglichen Zielgruppen, Detailgrade, Datenmodellen (z.B. für Routing) etwas was eine Entscheidung auf ganzer Linie erschwert.. und man arbeitet hier mit lauter freiwillige und nicht mit Angestellte denen Weisungen geben kann. Da hilft es nur möglichst an der Realität zu bleiben und es so gut wie es gerade geht zu machen..

Umtaggen mach ich nur wenn ich da einen Fehler, einen Nachteil bzw. ich das Objekt besser kenne bzw. das getagte absoluter Blödsinn ist.

Aktuell Zeichne ich Luftbild mit einem entfernten Gebiet.. ich mach die Grundkarte und setze Fehler die ich finde und ein Lokaler Mapper löst die Fehler und ergänzt noch die Daten. Der ist froh das er nicht bei null anfangen muss und schon eine Grundkarte da ist 🙂

In diesem Sinne

OT:

Nakaner wrote:

Es ist schade, dass er die Umfrageplattform nicht mehr betreibt, aber der Quellcode ist auf Github (bloß leider ohne Lizenzangabe und daher unfrei).

Klar ist da eine Lizenzangabe: https://github.com/it4workflow/osmpoll/ … icense.txt:

it4workflow/osmpoll is licensed under the MIT License

Hmm, diese license.txt kommt ursprünglich von https://github.com/nova-framework/v1 (formerly known as simple mvc framework) das ich geforkt habe... letztendlich sind aber auch sämtliche Programmierungen, welche ich für osmpoll (Umfrageplatform) gemacht habe frei bzw frei verwendet werden, sonst hätte ich damals schon nicht angeboten, dass das gerne geforkt und auch woanders aufgesetzt werden kann.