You are not logged in.

#76 2018-02-28 15:27:10

kreuzschnabel
Member
Registered: 2015-07-03
Posts: 6,187

Re: Grundlegende Probleme von OSM

wiki the map wrote:

Die Unvereinbarkeit hat einen Slogan, welcher lautet, wir Mappen nicht für den Renderer.

Ich darf meine übliche Erwiderung an dieser Stelle auspacken: Wir mappen aber auch nicht gegen ihn.

--ks


Verwaltungsverfahrensgesetz § 44 (1): Ein Verwaltungsakt ist nichtig, soweit er an einem besonders schwerwiegenden Fehler leidet und dies bei verständiger Würdigung aller in Betracht kommenden Umstände offensichtlich ist.

Offline

#77 2018-03-01 07:55:12

wiki the map
Member
Registered: 2015-02-01
Posts: 1,280

Re: Grundlegende Probleme von OSM

kreuzschnabel wrote:
wiki the map wrote:

Die Unvereinbarkeit hat einen Slogan, welcher lautet, wir Mappen nicht für den Renderer.

Ich darf meine übliche Erwiderung an dieser Stelle auspacken: Wir mappen aber auch nicht gegen ihn.

--ks

Übersetzung: im Renderer sind Regeln umgesetzt, und an diese hat man sich zu halten.

Also eine Knebel Regel,

Bei osm.org handelt es sich um ein deklariertes Werkzeug, warum für ein Werkzeug ein derart großes tam tam zwecks Einhaltung von restriktiven Regeln.
Wer legt diese Regeln fest, zu welchem Zweck?

Jeder kann sich aus OSM Daten seine eigene Karte bauen, wozu also diese Politik um osm.org

Grüße Johann

Offline

#78 2018-03-01 08:27:46

kreuzschnabel
Member
Registered: 2015-07-03
Posts: 6,187

Re: Grundlegende Probleme von OSM

wiki the map wrote:

Übersetzung: im Renderer sind Regeln umgesetzt, und an diese hat man sich zu halten.

Hä? Nein, das habe ich weder gesagt noch gemeint. „Wir mappen nicht gegen den Renderer“ heißt für mich „Wir mappen so, dass jeder Renderer mit unseren Daten optimal zu seinem Ergebnis kommen kann“.

wiki the map wrote:

Jeder kann sich aus OSM Daten seine eigene Karte bauen, wozu also diese Politik um osm.org

Es geht in diesem Thread genau darum, dass das eben nicht jeder kann (wenn nämlich seine IT-Fähigkeiten nicht dazu ausreichen), und dass wir deshalb Otto Normal schon auf unserer Projekt-Website eine etwas funktionellere Karte bieten sollten als die jetzt dort gebotene.

Es geht in diesem Thread genau darum, dass OSM viel, viel mehr kann als die Mapnik-carto-Karte auf unserer Projektwebsite ahnen lässt, aber die meisten unserer Besucher merken das nicht, weil halt das, was sie da sehen, in ihrer Wahrnehmung OpenStreetMap ist.

Und wir reden seit 76 Posts darüber, was man daran ändern kann, und dann fragst du im 77. Post, was das alles soll, es könne sich doch jeder seine eigene Karte bauen. Genau das war die Anfangsfrage. Rechtlich kann das jeder, ja. Aber 99 Prozent unserer Website-Besucher tun es halt nicht, sondern fragen nur: „Das ist alles?“

--ks


Verwaltungsverfahrensgesetz § 44 (1): Ein Verwaltungsakt ist nichtig, soweit er an einem besonders schwerwiegenden Fehler leidet und dies bei verständiger Würdigung aller in Betracht kommenden Umstände offensichtlich ist.

Offline

#79 2018-03-01 09:32:02

firstAid
Member
From: Oberbayern
Registered: 2016-02-10
Posts: 359

Re: Grundlegende Probleme von OSM

@Kreuzschnabel ... sehe ich genau so wie du ;-)

Eine Idee wäre doch... Overpass (mehr oder minder schön) fest in die osm.org zu integrieren (anstatt alles trennen zu wollen)... Es gibt heute kaum noch jemanden der nicht "Programmieren" in der Schule hatte und eine Overpassabfrage mit diesem simplen QL z.B. anhand von gut gewählten Beispielen bei denen man nur "Begriffe" austauschen muss, traue ich auch meiner 70'jährigen Mutter zu, die von OSM keine Ahnung hat... Meinetwegen auch mit "Bausteinen" die man sich draggen und droppen kann...

Wenn ich dich richtig verstehe @Kreuzschnabel könnten deiner Meinung "mehr" Daten der OSM dem Enduser (Otto-Normal) zur Verfügung gestellt werden, sodass das Interesse an den (vielfältigeren statt den oberflächlichen) Daten auch in der Bevölkerung ein großes Interesse findet und am Ende davon auch die OSMF wieder profitiert, da dann mehr Leute die OSM als etwas wichtiges und Unterstützenswertes halten?! --> Geld++

Und hier trifft auch meine Rede die Kernkritik, mangelnde "Zusammenarbeit" ... denn "Trennung" von OSM-Kerninhalten ist nicht dass was ich unter "Zusammenarbeiten" verstehe.

@wikithemap

Und den von dir genannten Slogan missdeutest du aus meiner Sichtweise ganz gewaltig...

wir Mappen nicht für den Renderer

ist nicht so gemeint, das wir am Ende nicht für eine Multifunktionale Karte mappen (natürlich tun wir das, und das ist und bleibt auf ewig einer der Kernpunkte der OpenStreet"MAP"... Und auch hier besteht in anderen Ländern noch viel viel Bedarf um wirklich alle Straßen zu mappen...

Der Slogan bedeutet viel mehr, dass wenn ein Renderer eine bestimmte Straße mit einer dünnen Linie anzeigt, dass du dann nicht einfach eine Autobahn mappen sollst, nur damit die Straße auch bei dem Renderer schön Dick dargestellt wird...

Der Slogan ist sogesehen einfach nur eine Erinnerung an den noch viel tiefer zugrunde liegenden Kernslogan:
Wir mappen das, was wirklich da ist(und wie es dargestellt wird, entscheiden die Renderer)

Last edited by firstAid (2018-03-01 09:40:36)


----
Für die Daten, nicht für die Renderer! :-)

Offline

#80 2018-03-01 10:16:13

emga
Member
Registered: 2014-05-21
Posts: 311

Re: Grundlegende Probleme von OSM

firstAid wrote:

@Kreuzschnabel ... sehe ich genau so wie du ;-)

Eine Idee wäre doch... Overpass (mehr oder minder schön) fest in die osm.org zu integrieren (anstatt alles trennen zu wollen)... Es gibt heute kaum noch jemanden der nicht "Programmieren" in der Schule hatte und eine Overpassabfrage mit diesem simplen QL z.B. anhand von gut gewählten Beispielen bei denen man nur "Begriffe" austauschen muss, traue ich auch meiner 70'jährigen Mutter zu, die von OSM keine Ahnung hat... Meinetwegen auch mit "Bausteinen" die man sich draggen und droppen kann...

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. ;-) bevor ich mich lange aufhalte mit einer Sprache, mach ich lieber ein workaround

Offline

#81 2018-03-01 13:48:27

wiki the map
Member
Registered: 2015-02-01
Posts: 1,280

Re: Grundlegende Probleme von OSM

firstAid wrote:

Der Slogan bedeutet viel mehr, dass wenn ein Renderer eine bestimmte Straße mit einer dünnen Linie anzeigt, dass du dann nicht einfach eine Autobahn mappen sollst, nur damit die Straße auch bei dem Renderer schön Dick dargestellt wird...

Der Slogan ist sogesehen einfach nur eine Erinnerung an den noch viel tiefer zugrunde liegenden Kernslogan:
Wir mappen das, was wirklich da ist(und wie es dargestellt wird, entscheiden die Renderer)

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.

emga wrote:
firstAid wrote:

@Kreuzschnabel ... sehe ich genau so wie du ;-)

Eine Idee wäre doch... Overpass (mehr oder minder schön) fest in die osm.org zu integrieren (anstatt alles trennen zu wollen)... Es gibt heute kaum noch jemanden der nicht "Programmieren" in der Schule hatte und eine Overpassabfrage mit diesem simplen QL z.B. anhand von gut gewählten Beispielen bei denen man nur "Begriffe" austauschen muss, traue ich auch meiner 70'jährigen Mutter zu, die von OSM keine Ahnung hat... Meinetwegen auch mit "Bausteinen" die man sich draggen und droppen kann...

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. ;-) bevor ich mich lange aufhalte mit einer Sprache, mach ich lieber ein workaround

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

Lg Johann

Offline

#82 2018-03-01 14:48:49

dooley
Member
From: Landkreis Calw
Registered: 2013-11-04
Posts: 698

Re: Grundlegende Probleme von OSM

wiki the map wrote:

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.

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


OSMsuspects! - QS-Tool Adressen Deutschland
Mein Avatar ist ein Ausschnitt aus "Die Saporoger Kosaken schreiben dem türkischen Sultan einen Brief (Ilja Repin)" (gemeinfrei)

Offline

#83 2018-03-01 16:14:16

MKnight
Member
Registered: 2012-08-01
Posts: 1,944

Re: Grundlegende Probleme von OSM

wiki the map wrote:

Die Realität ist doch, highway=residential wird vom Renderer aktuell in der Breite einer Autobahn gerendert

Nein.


gesammelte Overpass-abfragen zu QA (hauptsächlich Strassenfehler) + verschiedene Stats zu Strassen-eigenschaften

Offline

#84 2018-03-01 17:05:05

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,444
Website

Re: Grundlegende Probleme von OSM

wiki the map wrote:

Wer hat die Breite von residential so festgelegt und warum.

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/viewtop … 53#p686653
https://wambachers-osm.website/index.ph … -watchlist
http://blog.openstreetmap.de/blog/2018/ … iz-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/openstr … rto/issues

wambacher

Offline

#85 2018-03-01 17:05:40

glglgl
Member
Registered: 2014-06-19
Posts: 411

Re: Grundlegende Probleme von OSM

wiki the map wrote:

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.

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


glglgl

Offline

#86 2018-03-01 17:10:38

Gppes
Member
From: Leoben / Austria
Registered: 2015-12-15
Posts: 611

Re: Grundlegende Probleme von OSM

wiki the map wrote:

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

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

Offline

#87 2018-03-01 17:31:02

maxbe
Member
Registered: 2010-01-19
Posts: 3,087
Website

Re: Grundlegende Probleme von OSM

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

Offline

#88 2018-03-01 19:05:12

firstAid
Member
From: Oberbayern
Registered: 2016-02-10
Posts: 359

Re: Grundlegende Probleme von OSM

wiki the map wrote:

Wer hat die Breite von residential so festgelegt und warum.

Im Zweifel du selbst! Nämlich wenn du dir aus den Daten eine Map rendern willst ;-)

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

Uns gehts gut

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* ;-)

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" 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 ;-)


----
Für die Daten, nicht für die Renderer! :-)

Offline

#89 2018-03-02 07:32:16

wiki the map
Member
Registered: 2015-02-01
Posts: 1,280

Re: Grundlegende Probleme von OSM

firstAid wrote:
wiki the map wrote:

Wer hat die Breite von residential so festgelegt und warum.

Im Zweifel du selbst! Nämlich wenn du dir aus den Daten eine Map rendern willst ;-)

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

Offline

#90 2018-03-02 07:59:25

Luzandro
Member
Registered: 2015-12-16
Posts: 334

Re: Grundlegende Probleme von OSM

wiki the map wrote:

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.

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

Last edited by Luzandro (2018-03-02 10:54:17)

Offline

#91 2018-03-02 08:52:21

maxbe
Member
Registered: 2010-01-19
Posts: 3,087
Website

Re: Grundlegende Probleme von OSM

wiki the map wrote:

Du meinst, künftig soll also jeder Wikipedia Leser aus einer bereitgestellten formatlosen txt Datei, sich sein eigenes individuelles Reader Dokument produzieren.

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

Last edited by maxbe (2018-03-02 09:11:30)

Offline

#92 2018-03-02 10:30:38

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,444
Website

Re: Grundlegende Probleme von OSM

wiki the map wrote:

Ich möchte dass meine jahrelange Arbeit durch Bereitstellung in einer sinnvollen Form, gewürdigt wird.

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.

Offline

#93 2018-03-02 11:31:04

firstAid
Member
From: Oberbayern
Registered: 2016-02-10
Posts: 359

Re: Grundlegende Probleme von OSM

wiki the map wrote:

Du meinst, künftig soll also jeder Wikipedia Leser aus einer bereitgestellten formatlosen txt Datei, sich sein eigenes individuelles Reader Dokument produzieren.

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 ;-) Ich habe nämlich keine Ahnung von hydranten und /oder ob man die alle otg(ontheground) sieht oder nicht :-) - 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.

Last edited by firstAid (2018-03-02 11:42:26)


----
Für die Daten, nicht für die Renderer! :-)

Offline

#94 2018-03-04 13:04:45

Maturi0n
Member
From: Bavaria/Germany
Registered: 2014-06-09
Posts: 274

Re: Grundlegende Probleme von OSM

firstAid wrote:

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)

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.

Offline

#95 2018-03-04 15:18:44

firstAid
Member
From: Oberbayern
Registered: 2016-02-10
Posts: 359

Re: Grundlegende Probleme von OSM

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

Last edited by firstAid (2018-03-04 16:08:14)


----
Für die Daten, nicht für die Renderer! :-)

Offline

#96 2018-03-04 16:33:16

MKnight
Member
Registered: 2012-08-01
Posts: 1,944

Re: Grundlegende Probleme von OSM

firstAid wrote:

Zu gerne würde ich z.B. das Lanes-Schema um ein genaueres Spurenverlaufsmapping erweitern.

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


gesammelte Overpass-abfragen zu QA (hauptsächlich Strassenfehler) + verschiedene Stats zu Strassen-eigenschaften

Offline

#97 2018-03-04 18:13:45

firstAid
Member
From: Oberbayern
Registered: 2016-02-10
Posts: 359

Re: Grundlegende Probleme von OSM

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 ;-)
*nun geht es mit ihm völlig durch*
*duck und weg*

Last edited by firstAid (2018-03-04 18:16:24)


----
Für die Daten, nicht für die Renderer! :-)

Offline

#98 2018-03-05 09:24:40

SimonPoole
Member
Registered: 2010-03-14
Posts: 1,847

Re: Grundlegende Probleme von OSM

firstAid wrote:

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

Offline

#99 2018-03-05 10:37:47

glglgl
Member
Registered: 2014-06-19
Posts: 411

Re: Grundlegende Probleme von OSM

firstAid wrote:

z.B.

lanes:ref=relation/19603203242432

surface:ref=relation/19603246454612

Autsch.

Unter "lane:ref" und "surface:ref" könnte man dann ganz bequem Area-Surfaces mappen die die Straße abbilden...

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.


glglgl

Offline

#100 2018-03-06 19:07:55

firstAid
Member
From: Oberbayern
Registered: 2016-02-10
Posts: 359

Re: Grundlegende Probleme von OSM

uvi wrote:

Aber damit sind wir dann wohl schon fast in der Diskussion über Grundlegende Probleme: https://forum.openstreetmap.org/viewtopic.php?id=61424.
...meint Uwe

Ja da hast du eigentlich Recht ;-) 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

Last edited by firstAid (2018-03-06 19:08:54)


----
Für die Daten, nicht für die Renderer! :-)

Offline

Board footer

Powered by FluxBB