Grundlegende Probleme von OSM

Ich bin bei euch, Beispiele und auch das Wiki müssen aber in dieser Sache wesentlich besser werden, ich habe es nicht geschafft meine Anfrage so umzusetzen wie ich es gerne hätte. und ich bin schon ein bisschen Programmier fähig aber eher auf der mathematischen Seite.

Hab dann aufgegeben weil mich das ganze aufgeregt hat und unschön über JOSM filter gemacht. :wink: bevor ich mich lange aufhalte mit einer Sprache, mach ich lieber ein workaround

Die Realität ist doch, highway=residential wird vom Renderer aktuell in der Breite einer Autobahn gerendert, in der Not mappt dann das Volk eben innerörtliche Straßen als highway=service. Aber du lenktst vom Thema ab. Wer hat die Breite von residential so festgelegt und warum.

Ich schließe mich dem an, osm.org und overpass Turbo gemeinsam, das wäre großartig.

Lg Johann

“Das Volk” erfreut sich an “schmalen” innerörtlichen Straßen wohl nur kurz - sobald “das Volk” diese Daten zum routen nehmen möchte, stellt es schnell fest, dass das vielleicht eine weniger gute Idee war.

Die Breite (und anderes) legen eben die Leute fest, die daran arbeiten. Ich nehme nicht an, dass die Styles per Diktatur aufgezwungen werden - damit steht dir der Weg offen, dich dort einzubringen. Oder in jedem anderen Bereich.

Mich ärgert dieses permanente Rummäkeln sehr.

Nein.

Auch wenn du seit mehr als 3 Jahren dabei bist und der Begriff “Carto” hier mehrmals im Thread erwähnt wurde:

https://wiki.openstreetmap.org/wiki/CartoCSS
https://forum.openstreetmap.org/viewtopic.php?pid=686653#p686653
https://wambachers-osm.website/index.php/osm-software-watchlist
http://blog.openstreetmap.de/blog/2018/02/wochennotiz-nr-396/ (Kapitel “Karten”)
https://github.com/gravitystorm/openstreetmap-carto

Über den letzen Link bekommst du direkten Kontakt zu den Entwicklern.
Hier darfst du dich gerne einbringen https://github.com/gravitystorm/openstreetmap-carto/issues

wambacher

Erstens stimmt diese Aussage nicht, und zweitens würde, selbst wenn sie stimmen würde, die von dir behauptete “Not” nicht vorhanden.

Wenn ich innerorts der Meinung bin, dass highway=service richtig ist (z.B. Zufahrt zu Einzelobjekten) dann tagge ich das so. Dh. auch innerorts versuche ich ach das Tag von der Art/Nutzung der Strasse abhaengig zu machen. Liege ich hier falsch?

Lg, Gppes

Ich bin froh. In #1 ist ein Artikel verlinkt, der 15-20 Probleme aufzählt und Maturi0n hat noch 3 weitere genannt. 40 Beiträge später war das auf die Thematik Kartenstile eingedampft und ab ca. 85 gehts um die Frage, wie viele Pixel einer Wohnstraße in Zoomstufe x zustehen. Uns gehts gut :wink:

Im Zweifel du selbst! Nämlich wenn du dir aus den Daten eine Map rendern willst :wink:

Aber ich denke das haben jetzt schon genug Leute klar gemacht… Ich will nochmal auf @maxbe eigehen…

Ja eigentlich sehe ich das sogar genau so… Uns gehts nämlich tatsächlich gut im Vergleich zu vielen anderen “open”-Projekten :wink: Und ich will noch gar nicht von der Linux-Community mit ihren verschiedenen Idealen als schlechtestes Beispiel sprechen g :wink:

Und du wirst lachen, als ich damals das OSM-Bad-Manifest zum ersten mal las, fragte ich mich allen Ernstes: “Häää, Was will der jetzt?! Das ist doch kein großes Problem” :slight_smile: Und so sehe ich es heute auch noch. Viele der Dinge im Bad-OSM-Manifest sind meiner Meinung nach halb so schlimm wie dargestellt… Auch ich selbst überspitze, wenn ich sage, das die Community meiner Meinung nach das Hauptproblem ist…

Eigentlich gehts uns nämlich wirklich gut… Und das sieht man schon daran wie in Threads wie diesem mit Meinungen der anderen umgeganen wird… Ich lese hier im Forum (deutscher Teil) max. 10% geflame und 90% konstruktives Geschreibe (freilich unterschiedlicher Meinungen) und das halte ich für herausragend gut. Gut vieleicht bekomme ich auch nur 10% mit, so aktiv wie andere bin ich ja nun auch nicht :wink:

Du meinst, künftig soll also jeder Wikipedia Leser aus einer bereitgestellten formatlosen txt Datei, sich sein eigenes individuelles Reader Dokument produzieren.
Für die Konfiguration der dazu notwendigen Software, zuerst einen EDV Lehrgang in Linux belegen, für die individuelle Generalisierung ein Studium in Geografie, sowie Landkarten Design.

Ich denke Du überschätz den Konsumenten. Ich als einfacher Mapper möchte für Menschen arbeiten nicht für Firmen. Ich möchte dass meine jahrelange Arbeit durch Bereitstellung in einer sinnvollen Form, gewürdigt wird.

Lg Johann

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.