Grundlegende Probleme von OSM

Bitte nicht “das Volk” vereinnahmen. Wenn es tatsächlich eine Gasse ist, spricht auch nichts dagegen. Dass das auf so gut wie jede Straße in St. Johann in Tirol zutreffen soll, möchte ich jetzt einmal bezweifeln, aber ich habe auch keine Ortskenntnis

Der normale Leser nicht. Jemand, der Überschriften gerne weniger breit und dafür kursiv will oder Infoboxen grün hinterlegt muss sich tatsächlich seinen eigenen Stil schreiben. Angemeldete Nutzer können auch unter Einstellungen → Aussehen → Oberfläche ein paar verschiedene Stile (Skins genannt) ausprobieren. Man kann sicher auch irgendwie in der Wikipedia an der Stilentwicklung für alle Nutzer konstruktiv mitwirken.

Nachtrag: Die Wikipedia hat sogar unser “Mappen für den Renderer”-Problem: Leute machen Überschriften mit ‘’’ statt ===. Macht alle Struktur und Auswertungsmöglichkeiten kaputt, aber “Fett” ist eben hübscher als “Überschrift”.

Sorry, aber nur “Mögen”, “Wollen”, gar “Fordern” ist nicht das, wovon OSM lebt. Ich nehme an, dass du dich bereits an die Entwickler gewendet und dort deine Mithilfe angeboten hast, gell?

Dass OSM nicht so “tickt” wie Wikipedia, ist dir ja auch schon aufgefallen. OSM wird jedenfalls nicht jährlich mit nahezu erpresserischen Maßnahmen einige Millionen $ einfordern, ansonsten wird der Laden dicht gemacht.

Ach ja, mit Maperitive(*) kann man sich relativ einfach lokale Karten erstellen, die einen persönlichen Style haben. Dort kannst du dich austoben und die reale Welt der Renderns kennen lernen.

wambacher

*) Ja, das läuft auch unter Windows und Mac OS.

Nein natürlich nicht… Denn der Vergleich hinkt. Bei Wikipedia ist das Konzept der Datensammlung nachrangig*. Es ging darum Wissen zu vermitteln und zu sammeln (also das Produkt aus Daten) - und da stand von Anfang an die “Methode” auf einer gleichen Ebene wie die “Inhalte”…

Du müsstest den Vergleich vielmehr darauf aufbauen, dass die Artikel nicht redaktionell im Endformat “produziert” sondern aus den Daten von “WikiData” generiert werden… So ist nämlich das Konzept der OSM. Zuerst die Daten → Dann wird daraus das Endformat generiert. Bei Wikipedia wurde das Endformat schon bei der Produktion berücksichtigt - und da ich nicht nur bei den Anfängen der OSM dabei war sondern auch bei den Anfängen von Wikipedia, weiß ich noch um die endlosen “Wie stellt man das dar”-Diskussionen die immer schon Teil der Wissensvermittlung waren (siehe auch Aufrufe nach Skizzen und Fotos, die damals allgegenwärtig waren)… Bei OSM hat sich diese Methodik aber schon recht früh aufgeteilt in die “Erfasser” und in die der “Darsteller” die teilweise und überwiegend auch in beiden Lagern tätig sind und waren.

Kurzgesagt: Wikipedia und OSM lässt sich bis zu einem gewissen Grad vergleichen, aber im Grundsatz sind es verschiedene Konzepte der Wissensvermittlung… Wenn ich jetzt Hydranten mappen würde, würde mich nicht interessieren wie die “normalen Renderer” diese Informationen verarbeiten. Mir ginge es darum, dass die Daten in OSM enthalten sind und “die” Renderer wie z.B. https://www.osmhydrant.org/de/, “die” sich darauf spezialisieren die Daten nutzen können. Bei “nicht-On-The-Ground-sichtbaren” Dingen ist m.M.n. sogar eine andere Datenbank pflicht (z.b. wie bei der http://www.openhistoricalmap.org).
Man korrigiere mich bitte wenn osmhydrant sogar eine eigene DB verwendet :wink: Ich habe nämlich keine Ahnung von hydranten und /oder ob man die alle otg(ontheground) sieht oder nicht :slight_smile: - Es war nur ein Beispiel.

Wikipedia hat aber einen anderen Ansatz… dort geht es darum, dass die Artikel allgemeingültig und für jeden lesbar sind. Nicht umsonst wird in der Wikipedia heftigst um Formulierungen in hochwissenschaftlichen Artikeln gestritten oder in politisch brisanten Bereichen…

OSM heißt: Daten erfassen und daraus Produkte generieren (Karten, Abfragen, etc.pp)
Wikipedia heißt: Das fertige Wissen(sprodukt) erfassen und weitervermitteln und als Bonus daraus Daten zu generieren (WikiData)

*erst mit dem aufkommen der semantischen Wikipedia hat man Angefangen die Daten über WikiData zu sammeln und aus den Artikeln zu extrahieren und geht damit eigentlich sogar den umgekehrten Weg wie OSM.

Naja, Allgemeingültigkeit bzw. Neutralität ist ja auch bei OpenStreetMap ein wichtiges Thema. Es gibt etliche umstrittene Regionen, wo auf OSM versucht wird, möglichste beide Standpunkte zu berücksichtigen. Ich denke was Neutralität/Allgemeingültigkeit angeht, ist der einzige Unterschied zwischen Wikipedia und OSM, dass sich Neutralität/Tendenziösität in Artikeltexten wesentlich schwerer definieren lässt, als auf Kartendaten. Auf OSM ist die Krim sowohl als Teil der Ukraine als auch Russlands erfasst, basta, das spiegelt beide Standpunkte wieder. Auf Wikipedia steht dazu ein ellenlanger Text über das Referendum von 2014, Völkerrecht, Verfassungen und UNO-Resolutionen und trotzdem klingt der Artikel für mich nicht neutral.

Ich glaube vom grundsätzlichen Ansatz her sind sich OSM und Wikipedia sehr ähnlich, der Hauptunterschied ist einfach, dass Wikipedia ein fertiges “Produkt” ist, während OSM.org bestenfalls ein sehr rudimentäres Produkt ist. Grundsätzlich kann sich jeder auch die Wikipedia-Datenbank nehmen und damit ein eigenes Lexikon bauen.

Um nochmal auf deinen Eingangspost zurückzukommen…

Was ich sehr sehr schade an OSM finde ist, das ich keine Datenrdeundanz-Verküpfungen ziwschen Merkmalen und Points/Ways/Areas erzeugen kann.

Zu gerne würde ich z.B. das Lanes-Schema um ein genaueres Spurenverlaufsmapping erweitern. Auch das Straßenmapping würde ich gerne um ein Areamapping erweitern - wenn es nach mir ginge. Die Struktur der OSM gestaltet dies aber grundsätzlich als schwierig, da wir zwangsläufig in Redundanzen laufen, deren Vermeidung mir vom Grundsatz her noch wichiger ist…
In den Anfängen wurde seitens der Community der Richtungshebel damals ganz klar hin zur Abstraktion gelegt… (was in vielen Regionen der Welt meiner Meinung nach auch immer noch Prio hat und haben sollte).

In den gut gemappten Regionen beobachte ich aber seit Jahren, dass die Abstraktion durch das “What-I-See-Is-What-I-Map” (WISIWIM)-Prinzip in den Hintergrund rückt und OSM heute schon in einigen Regionen dem Ortsunkundigen den Blick auf Satelliten-Ansichten von Google,Bing und Co. ersetzt z.B. wenn man sich einen Überblick über die Lage am z.B. Urlaubsort machen will… Bezirke, Regionen, Wälder, Häuser, Bäume, Flüsse… Alles wunderbar erfasst und sichtbar… Nur wenn ich über den mehrspurigen Kreisel in Frankreich muss, habe ich keine Ahnung wie ich dort fahren soll (und wer schon mal französische Großkreisel mit mehreren Spuren live gesehen hatte, der weiß, dass man darin gefangen wird, wenn man nicht weiß wie man da fahren muss :wink: ). Bei Straßen (und insbesondere den Lanes und Straßenflächen) sehe ich deshalb das Problem, dass eine Nicht-Abstrakte Erfassung zwar (aus meiner Sicht) sehr toll wäre, diese aber Redundanzen mit den abstrahiert erfassten Daten erzeugen würde.

Schön wäre es deshalb meiner Meinung nach, wenn man diese Dinge logisch verknüpfen könnte - und sozusagen als Merkmal auch einen Punkt, einen Way oder eine Area refferenzieren könnte…

z.B.
highway=residential
lanes=3
lanes:forward=2
lanes:ref=relation/19603203242432
lit=yes
maxspeed=50
name=Straßenname
smoothness=good
source:maxspeed=DE:zone
surface=asphalt
surface:ref=relation/19603246454612
turn:lanes:forward=left|right

Unter “lane:ref” und “surface:ref” könnte man dann ganz bequem Area-Surfaces mappen die die Straße abbilden… oder Lane-Ways die den genauen Verlauf der Lanes angeben… sodass diese Daten in gut gemappten Gebieten zusätzlich erfasst werden können und wir am Ende sowohl das Abstrakte Straßenbild als auch das physikalische Straßenbild erfasst haben… Die Renderer können dann je nach Gebiet entscheiden, welche Version (je nach Datenqualität) besser geeignet ist um sie dem Enduser zur Verfügung zu stellen.

Kurz:
Die Erweiterbarkeit bei den Straßen also der “Pulsadern” der OSM (Abstraktion->Realität) sehe ich als Problem der OSM.

Gehört das wirklich (grundlegend) noch hierher, oder in einen Extrathread? Schau Dir mal https://wiki.openstreetmap.org/wiki/DE:Key:destination:ref an, da könnte, was diesen Punkt betrifft, geholfen werden.

MKnight… das ref was du meinst hat aber mit meinem Text eigentlich gar nichts zu tun, oder ich verstehe nicht in wie weit es meine “grundlegende” Problematik betrifft? Der Thread ist doch gedacht um grundlegende Probleme zu sammeln - so habe ich zumindest Maturi0n verstanden. Und ich finde es schon sehr grundlegend wenn Abstraktionen die früher (und heute in vielen Gebieten immer noch) die Verbesserung der Map grundlegend einschränken… Ich glaube ich bin da falsch verstanden worden… meine “ref”-bezeichnung war in diesem Fall willkürlich und sollte lediglich zeigen, das das was ich gerne machen würde nicht geht :wink: Da hätte auch “surface:@pointerAufEinenAnderenDatenbankEintag” stehen können…

Was gemeint war, war eine “Referenz” (im Sinne einer Programmiersprache) also als Merkmal nicht einen Text einpflegen sondern eine Referenz auf eine andere Datenbank-Node/Way/Area…

Im Prinzip könnte man mit sowas auch Relationen abschaffen :wink:
nun geht es mit ihm völlig durch
duck und weg

Kurze technische Bemerkung: mit einer Relation könnte man so was tatsächlich halbwegs korrekt modellieren da unser Datenmodel und die API referentielle Integrität für die Referenzen in Relationen unterstützen. Hingegen sind Objektreferenzen in Tags ein Defekt (und ein Taggingschema, dass die gemacht hat ist auch prompt gescheitert).

Autsch.

Ach so. Dann sollte man aber nicht auf die von dir beschrieben Weise dorthin referenzieren, sondern umgekehrt das aktuelle Objekt irgendwie in die Relation einfügen. Allerdings kann ich mir unter einer surface- oder lane-Relation nichts vorstellen, von daher fällt es mir schwer, da ins Detail zu gehen.

Ja da hast du eigentlich Recht :wink: Indoormapping ist auch so ein grundlegendes Problem… Vor allem eines, was die in der Bevölkerung als solche wahrgenomme “Konkurrzenz” aus dem Hause Google richtig gut kann… “Ranzoomen” bis man auf die Indoor-Ebene kommt und dann Ebenen durchschalten (das vermisse ich schmerzlich in OSM - vorallem bei größeren Kauftempeln)

P.S. Diesen Beitrag kreuzverlinke ich mal aus gegebenem Anlass in beiden Diskussionen damit man eine jeweilige Referenz hat

  1. Indoormapping Supermärkte/Baumärkte
  2. Grundlegende Probleme von OSM

Irgendwie tut Verlinken, gar nichts, aber auch wirklich gar nichts dazu um Probleme, seien es wirklich grundlegende oder nur vermeintliche, zu beheben. SIT kann locker all deine Indoorbedürfnisse abdecken, wenn du eine genügend perfomante Infrastruktur mit einer entsprechenden Karte (kannst ja OpenLevelUp forken) zur Verfügung stellst, integriere ich das gerne in openstreetmap.org, versprochen.

Das Problem ist: Es wird zuviel gelabert und zuwenig gemappt. :sunglasses:

Lieber SimonPoole… Einer von uns beiden hat den Thread falsch verstanden denke ich…

Die Auforderung für diesen Thread war doch… Weitere Probleme zu sammeln (analog zu der Liste https://blog.emacsen.net/blog/2018/02/16/osm-is-in-trouble/)

Es geht hier meiner Meinung nach überhaupt gar nicht darum Probleme zu beheben… Es geht darum, sie überhaupt erst mal zur Sprache zu bringen… Wenn “Indoormapping” für dich und andere kein Problem ist, gut… dann bemessen wir dem keine Relevanz zu und gehen weiter… Ist doch auch ein gutes Ergebnis wenn man sagen kann “Indoormapping ist kein grundlegendes Problem”

Mir ging auch gar nicht so sehr um die Darstellung und die “Bedürftnisse” des Indoormappings… Ich habe nur den Gedanken von @uvi aufgegriffen, weil für mich Indoormapping auch zu den grundlegenden Problemen gehört…

Ein schönes Beispiel ist meiner Meinung nach z.B. https://www.openstreetmap.org/search?query=Rheingalerie die Rheingalerie in Ludwigshafen. Hier wäre ein besseres Mapping m.M.n. dringend nötig, schon alleine weil man auf dem Parkdeck sonst überhaupt nicht vernünftig navigieren kann bzw. gefahr läuft im Zweifel die falsche Ausfahrt zu nehmen und einen (je nach Verkehr) 20min Umweg einplanen kann… Ans Mapping traut sich aber seit Jahren niemand ran (wird auch offen disskutiert) weil man eigentlich den ganzen Einkaufstempel drunter direkt mitmachen müsste (zumal es 2 Parkdecks gibt)… Vom echten Indoormapping mit “aufgeteilten” Bereichen rede ich da noch nicht mal…

Ich persönlich finde fehlendes Indoormapping von solchen Locations einen gravierenden Nachteil der OSM.

Mal abgesehen davon dass ich hier nur ein grundlegendes Problem “verlinken wollte”… zeigst du doch mit dieser Aussage sehr schön das es offensichtlich also doch ein “grundlegendes” Problem mit der derzeitigen Lösung gibt… oder verstehe ich das falsch? Sonst wäre es ja umgesetzt und man müsste nicht noch was machen müssen…

Ich weiss auch wer.

“grundlegend” sind Sachen die in der Natur des Projektes oder mindestens an der jetzigen Ausprägung liegen. Ganz sicher nicht, dass etwas noch nicht in allen Details in den Daten erfasst ist. “grundlegend” wäre z.B. wenn man die Rheingalerie aus irgendwelchen Gründen nicht erfassen -könnte-, nicht. dass du es einfach noch nicht gemacht hast.

Wobei auffällige Schwächen im Datensatz in bestimmten Bereichen für mich schon ein grundlegendes Problem sein können.

Den Mangel an Adressen in OSM empfinde ich z.b. als grundlegendes Problem. Das wird auch schwer ohne Bereitstellung von Daten durch Dritte zu lösen sein. Die doch recht begrenzte Zahl an OSM-Nutzern wird das nicht alleine schaffen.

Ja dann ist doch alles bestens :wink:

Dann gibt es fast keine grundlegenden Probleme weil man ja einfach alles mit einem “-könnte-” abschmettern kann… und daher niemals irgend eine Diskussion angestossen werden würde…

Man *könnte *statt Nominatim einfach Pelias oder Photon vorantreiben…
Man *könnte *neue Mapper zunächst auf einer Neulings-DB mappen lassen wo sie sich erst bewähren müssen und erfahrene Mapper nur die guten Mappings in die OSM übernehmen…
Man *könnte *Moderation einführen…
Man *könnte *Vandalismus eindämmen, in dem man nur geprüfte (Autoren) auf der echten OSM-DB mappen lässt…
Jeder *könnte *sich immer eigene bessere Tools schreiben, die alles viel besser können als die vorhandenen…

usw. usf. Dann haben wir ja die Liste der Probleme schnellstens abgehakt, weil fast alles keine grundlegenden Probleme mehr sind. Immerhin *könnte *man ja aus einer Datenbank fast ALLES möglich machen.

Nochmal: Ich sage nicht, dass Indoormapping ein grundlegendes Problem IST.
Wir sammeln hier einfach nur Themen in denen die OSM schwach ist und über deren Gewicht und Ursache man diskutieren und streiten kann.

Am Ende kommen dann vieleicht mal die Punkte heraus, die die deutsche Forum-Community überwiegend als “grundlegend” ansieht. Wenn Indoormapping da nicht mit bei ist - kann ich gut damit leben! Aber Sammeln wird man ja noch dürfen oder?

Der Punkt des Threadstarters mit er Adress-Vollständigkeit wäre aber in deinem Sinne ja dann auch nicht “grundlegend”. weil sich ja Adressen “grundlegend” erfassen lassen. Dennoch ist es aber ein Teil der Frage des OT gewesen und damit sind solche und artverwandte Probleme in diesem Thread meinermeinung nach gefragt. Der Threadstarter möge mich bitte korrigieren und mir sagen, dass es nicht so gemeint ist. (dann bin ich ganz flux hier aus dem Thread raus - kann ja wirklich sein, dass ich es Falsch verstanden habe)

Solange jedoch bleibe ich dabei.
Ich finde, das der “Indoor-Mapping”-Punkt sehr gut in diese Reihe der noch zu erwähnenden Probleme passt.
Wenn du das anders siehst -wobei du ja selbst die performance als Problem angesprochen hast und dich damit ja sogar eigentlich widersprichst - dann ist es doch auch okay.

Hab ich da irgendwo einen wunden Punkt getroffen? Wenn ja - war nicht meine Absicht!

edit: (ich war gerade am schreiben während OT sich gemeldet hat)

Und genau so sehe ich das z.B. auch beim Indoormapping… mehr als eine verlinkung aus diesem Grund sollte es eigentlich gar nicht werden :wink: Aber wenn man sich für solche Verlinkungen rechtfertigen soll, dann mache ich das natürlich gerne…

Ich glaube das Missverständnis hier kommt aus unterschiedlicher Herangehensweise an Probleme.
Indoormapping ist kein grundlegendes Problem von OSM, sondern fehlende Mapper. Das betrifft diverse andere Sachen auch (schlechte Qualität, mangelnde Daten und und und). Warum muss man das hier mit immer mehr Details zerreden, das “Problem” ist doch eindeutig?

Moin Zusammen,

kein grundlegendes Problem, nur eine kleine Abweichung von der Norm :wink: :

Auf der osm.org Seite wird kein neuer Browser-Tab aufgemacht, wenn man auf die Verlinkung einer Website (website=* / contact:website=*) z.B. eines POI’s (https://www.openstreetmap.org/node/339233227) => http://www.bittenfelder.de drückt. Ist das so gewollt?

Beispiele für Kartentools bei denen einen neuer Browser-Tab geöffnet wird sind maps.google oder die Öffnungszeitenkarte (http://openingh.openstreetmap.de/?zoom=18&lat=48.8917&lon=9.32273&layers=B0T&filter=none&tags=opening_hours)

Schöne Grüsse
AB

Da gibt es wohl wieder zwei Parteien, die eine, die den User dazu zwingt und einfach ohne zu Fragen einen neuen Tab aufmacht, oder eben die andere, die den User die Freiheit lässt … du musst einfach nur beim Klicken des Links die “STRG”-Taste drücken, und schon geht bittenfelder.de in einem neuem Tab auf.