Verständnisfrage zum "Renderer" bzw. zu Symbolen

Hallo, hab ich es richtig verstanden: was mir im Web als OSM-Karte gezeigt wird, ist bezüglich der graphischen Darstellung im wesentlichen durch die vom “Renderer” verwendeten Regeln bestimmt, der Kartenersteller hat keine Gestaltungsmöglichkeit ? Beispiel: ein Hotel wird als “tourism->hotel” mit Bezug auf einen Punkt durch das voreingestellte Icon mit dem Bett abgebildet, es erscheint erst in der höchsten Zoomstufe und wird von einer optionalen Beschriftung - die evtl. schon vorher erscheint - begleitet. Sicherlich haben sich schon viele darüber gestritten, ob das im Auge des Betrachters gut oder schlecht ist, es hat ja auch logischerweise in der jeweiligen Zoomstufe bzw. dem jeweiligen Maßstab Vor- und Nachteile. Wenn ich dieses “Problem” lösen will, muss ich mir also meinen eigenen “Renderer” bauen. OSM ist - wenn ich auch das richtig verstanden habe - in erster Linie als Sammlung von (geometrischen?) Daten gedacht, nicht als Web-Anwendung zur Anzeige von Karten. Frage: wäre es nicht sinnvoll bzw. zumindest diskussionswürdig, eine Steuerung der Größe und der minimalen Zoomstufe für die Anzeige von Symbolen mit einigen zusätzlichen “Tags” in die “Renderer” aufzunehmen? Das ganze also nicht nur den “Renderer” machen zu lassen, sondern die Karte tatsächlich selbst zu gestalten… Etwas ähnliches geschieht doch schon mit der Beschriftung eines Symboles, die interpretiert der Renderer doch auch. Was nützen denn die schönen Daten, wenn die Web-Karte - die ja wohl derzeit eine der wesentlichen Anwendungen ist - doch ein wenig “mager” aussieht… Das sollte als konstruktive Kritik verstanden werden, ich will in keiner Weise die Arbeit der Beteiligten schmälern, kann mir z.B. den Job der “Renderer”-Programmierer gut vorstellen, da ich zufällig auch Kartograph bin :slight_smile: Was denk ihr so? Gruß W

Hallo Claus,

Ja, das ist richtig

Klar haben wir diese. OSM besteht ja a) aus einer riesigen Geo-Datenbank b) aus den Anwendungsprogrammen Beides wir opesource von UNS erstellt. Das Problem dabei ist, dass die verschiedenen Entwicklergruppen sehr wenig miteinander vernetzt sind. Und wenig direkt miteinander kommunizieren. So stellen sich dann alle Datensammler dieselben Fragen wie Du. Einerseits gilt: “wir arbeiten nicht für die Renderer”, also wir sammeln die Daten so, wie es für die Datenstruktur sinnvoll ist, und hoffen, dass die renderer ihrerseits etwas Sinnvolles daraus machen. Dabei ist es durchaus üblich, dass eine neue Datenstruktur (Dein Hotel beispielsweise) schon lange existiert, aber noch immer nicht sinnvoll abgebildet wird. Gleichzeitig ist es natürlich das ureigene Interesse eines jeden Datensammlers, dass “seine” Daten möglicht sinnbringend abgebildet werden. Deshalb versuchen manche immer wieder zu “erraten”, wie denn die Renderer arbeiten, und dann “schraubt” er entsprechend an seinen Daten rum, in der Hoffnung, dass die Darstellung nun besser wird… Mein Lösungsversuch: a) alles was ich an Regeln entdecke: im de:Wiki dokumentieren b) alle bitten ihre Ideen im de:Wiki und im en:Wiki zu dokumentieren c) hemanden bitten, de:Wiki nach en:Wiki zu übersetzen d) für alles was ich im en:Wiki als sinnstiftend entdecke um Übersetzung nach de:Wiki bitten e) möglichst alles möglichst strukturieren und sinnvoll verlinken f) reden, reden, reden

Das ist keine gute Lösung, denn zersplittert sich das Projekt und verliert an Energie, dadurch entsteht ein Wildwuchs, der bald nicht mehr zu handhaben wäre. Besser ist: Bei den bestehenden Renderern mitarbeiten, sinnvolle Render-Regeln entwickeln, in enger Zusammenarbeit zwischen Datensammlern und Rendererentwicklern.

Nein. Denn da würde JEDER etwas anders reinschreiben wollen. Hingegen würde Sinn machen, die Elemente und ihre Attribute in individuell wählbaren Ebenen darzustellen. Beispielsweise alle Wanderwege für die Wanderer, alle Kneipen und Discos für die Nachtschwärmer, alle Sehenswürdigkeiten für die Touristen, alle Löschwasserentnahmestellen für die Feuerwehr, etc, etc. ür die Das ganze also nicht nur den “Renderer” machen zu lassen, sondern die Karte tatsächlich selbst zu gestalten…

DEM ist nichts hinzuzufügen… Packen wirs an! Gruss, Markus

Genau das mit den “Ebenen” fehlt mir auch. Also die Funktion gezielt verschiedene Arten von POIs und Wegen ein- und auszubleneden. Ich hoffe, da wird nochmal etwas folgen.

Für die POIs gibt es so etwas schon unter http://www.lenz-online.de/cgi-bin/osm/osmpoinit.pl Grüßle, detlef

Hallo Markus und die anderen, die fehlende Kommunikation zwischen den Developern und den Benutzern (Sammlern von Daten) usw. ist ein Problem, ok, sehe ich. Werde mich also mal dort umschaun :slight_smile: Was ich aber ein wenig anders sehe: derjenige, der einen GPS-Track macht, ihn aufbereitet und hochlädt, derjenige ist auch in gewissen Rahmen für die kartographische Gestaltung zuständig, das geht einfach nicht automatisiert durch einen Renderer… Derartige Versuche wurden in den 80er Jahren mit kartographischen Konstruktionssystemen gemacht, die sich auch formalisierter Regeln bedient haben. Es wurde sehr viel Wissen (Datenmodellierung, Zeichenmodellierung usw.) beschrieben und in ein entsprechend “intelligentes” System gesteckt… und es hat alles nicht so recht funktioniert… Eine Karte ist von vielen Dingen (Anwendungszweck, Maßstab, Gestaltungsmöglichkeiten, geometrische und graphische Struktur, Zeichenvorrat…) abhängig, die kann als automatisch generierte Abbildung nicht gut aussehen. Wer also ist besser geeignet, den Feinschliff (graphisch) an einer bestimmten Karte zu machen, als derjenige, der die Daten erhoben hat - in der Annahme er kennt sich also in dem Gebiet aus??? Mein Beispiel wär - zumindest in meinen Augen - recht sinnvoll umsetzbar: standortbezogene Objekte bzw. punktförmige Zeichen/Symbole werden mit Hilfe von ein oder zwei Tags “gesteuert”. Der Kartengestalter kann dort natürlich nicht sagen “ab Zoom 1, Grösse immer 36x36px”, das sollte nicht gehen. Was aber z.B. gängige Praxis ist: die Anteile der punktbezogenen Zeichen an der Kartenfläche soll bei 5, 6 oder 7% liegen… Derartige Tags können, müssen nicht benutzt werden, wer es aber tun will, sich ein wenig damit beschäftigt, der wird deutlich bessere Karten sehen… Aber wem sage ich’s, das geht natürlich an die Adresse der Entwickler… Aber nochmals: hat nicht jeder, der “sein” Gebiet bearbeitet, auch eine gewisse Verpflichtung gegenüber der Kartengraphik??? Noch ein Satz zu den Ebenen: es ist ja eigentlich nichts anderes als eine dynamische Ausrichtung der Basiskarte hin zu einer bestimmten Thematik (wie auch im Begriff der thematischen Karte…). Das ist aber letztlich nur die Auswahl anzuzeigender Inhalte bzw. ihrer graphischen Repräsentationen in Form von Symbolen etc. Aber auch hier gilt: das einzelne Zeichen (auch wenn es über eine thematische Auswahl entweder einen Radweg, ein Bushaltestellensymbol usw. ist) ist damit noch nicht an die Bedingungen der Web-Karte (Bildschirmgrösse im Verhältnis Zoomstufe…) angepasst. Ich will hier nicht weit über das hinaus, was im Rahmen eines solchen Projektes “gefahrlos” möglich ist, eine Sache wie die Erkennbarkeit/Sichtbarkeit von Symbolen gehört jedoch in meinen Augen dazu. Ach ja, eins dazu noch, direkt zu Markus: an den Daten “rumschrauben” um die Darstellung zu verbessern, tja, Schummeln gilt nich :slight_smile: Werde mich im Kreise der “Renderer” mal umtun, wenn jemand einen Kontakt hat, teilt ihn mit bitte. Wobei die ja eigentlich auch nur fest definierte Konfigurationswerte benutzen (die XML-Files), da stehen nur Werte drin, keine Funktionsdefinitionen… Ansonsten bin ich immernoch ziemlich beeindruckt von OSM, werde wohl bald mal ein wenig beisteuern :slight_smile: Gruß W

Hi “ClausKrueger”,

IMHO beisst sich die rhetorische Frage mit Deiner Feststellung vorher:

Weil “der Mapper” genauso diese Faktoren nicht kennt, sollte er mE nur in “kontrollierten Ausnahmefällen” überhaupt versuchen, auf ein späteres Rendering “seiner” Daten Einfluss zu nehmen. Ausserdem dürfte es eher die Ausnahme und auch nicht unbedingt erwünscht sein, dass nur ein Mapper ein bestimmtes Gebiet alleine mappt (kein peer review). Er kann also gar nicht beurteilen, wer später welche anderen POIs erfasst und welcher Renderer ein paar Monate später welche Features wie abbildet. Daher besser: komplette Trennung von Mapping und Rendering.

Kein Zweifel - nur: wie soll der Mapper das denn bestimmen - wie soll er die 7% auswählen? Insbesondere da er den Datenbestand zum Zeitpunkt des Renderings nicht kennen kann? Gerade so eine Regel macht doch gerade nur im Regelwerk eines Renderers Sinn, nicht aber im Datenbestand - denn sie greift schließlich erst dann.

IMHO: klar nein. Denn er kann gar nicht überblicken, wer wann mit welcher Zielsetzung auf welchem Endgerät aus den Daten eine Grafik generieren wird. Deswegen hat er IMHO nur eine “gewisse Verpflichtung”, zwecks Aufbaus eines konsistenten Datenbestandes im Einklang mit den anerkannten Mapping-Regeln zu mappen. Mehr ist IMHO gar nicht möglich. Gruss florian

Also ich fänds super, wenn du einen eigenen Renderer bauen würdest, der sich von den bestehenden Renderern unterscheidet. (So wie es die Entwickler der Cyclemap gemacht haben) Für die Darstellung sollten aber die Renderer verantwortlich sein. Meiner Meinung nach fehlt den Renderern noch die Regel: “POIs, die von geringer Bedeutung sind, sollen trotzdem dargestellt werden, wenn es kaum andere POIs in der Umgebung gibt, und keine anderen Objekte überlagert würden.”

Hallo Forum, da diese Diskussion ins Grundsätzliche geht: Es muss ja hier irgendwo einige Leithammel geben, die die Herde anführen. Diese Leithammel stellen nach meiner Meinung zu wenig Richtlinien auf. Z.B. Ich vermisse eine konsequente Anwendung des Layer-Prinzips (oder habe ich da etwas nicht verstanden?). Alles was **wichtig **ist, wird zuerst gezeigt (Übersichten). alles was Nebensache ist, wird zuletzt (Zoom 17) gezeigt. Eine Kartenlegende muss da sein, aus der hervorgeht, dass Biergärten nur in Z17 (z.B.) gezeigt werden, Bus-Haltestellen in Z15 usw usw. Oder: richtet Themen-Layer ein: “Zeige alle Biergärten…”, “Zeige alle Buslinien…” Wie diese Strukturen dann aussehen, muss ausdiskutiert werden. Wichtig ist aber, dass sie dann auch eingehalten werden. Man muss die Programmierer der Render eben auch überreden, so vorzugehen. Jetzt sagt mir nicht, dass es das doch gäbe. Wenn es das gibt, dann ist es weitgehend unbekannt oder es wird nicht durchgesetzt. Ich wünsche ein schönes Wochenende Frank

Hallo Frank, ich sehe im Projekt keine Leithammel. Es gibt einige sehr aktive (was die Anzahl der gemappten Objekte angeht) und kommunikative (was die Foren- und Mailinglistenbeiträge angeht). Persönlich denke ich aber, dass keiner von denen sich selbst als Leitfigur sieht in dem Sinne, dass er (oder auch sie?!) mehr zu sagen hätte als andere. Die, die zb. die Renderer geschrieben haben, haben sich einfach hingesetzt und losgelegt. Und dann natürlich alles so gemacht wie es ihnen am Besten erscheint. Die gerenderte Karte ist nicht das (einzige) Ziel von OSM. Genau genommen ist die Aussage “wir mappen nicht für den Renderer” falsch. Es sollte eher heissen “ich mappe nicht für den Renderer”. Wenn jemand eine hübsch anzusehende Karte im Sinn hat, warum nicht… Solange er die Daten nicht in seinem Sinne verbiegt. Mir ist es z.B. wurscht, was für einen Tracktype ein Weg hat. Das Ziel das ich vorrangig anstrebe ist eine funktionierende KFZ-Navigation, da interessieren mich Tracks nur am Rande. Daher hab ich auch noch nie einen Tracktype getagged. Wenn es jemand nachträgt gerne, soll mich nicht stören. Das gleiche sehe ich bei Markus und seinen Layern. Wenn er keine lust hat welche zu taggen, hab ich kein Problem damit. Solange er keine Layers löscht, weil sie ihm überflüssig erscheinen… Jetzt der Schwenk zurück auf das Legendenthema… Wünschenswert wäre ein Renderer, der für Normalsterbliche ohne größere Programierkenntnisse anpassbar ist. Dem man sagen kann welche Objekte man ab welcher Zoomstufe sehen will, bei denen auch Icons und Icongröße selbst definiert werden kann. Wird sicherlich auch irgendwann kommen, steuerbare POI hat Paul Lenz ja schonmal gebastelt. Gruß vom zorque

Danke, zorque. Für alle, die diesen Thread mitlesen: Das wär’s ja. Es geht ja auch. Bei Kosmos kann man sich seine eigenen Rules basteln. In der derzeitigen Version muss man aber die ganze Karte in den Ram laden. Versucht das mal bei Deutschland: 2,7GB. Da machen normale Rechner die Grätsche. Wird schon noch werden! Frank