Ich hoffe, dass ich nicht ein altes Thema jetzt hier aufwärme (über die Suche bin ich nicht fündig geworden), ansonsten bitte ich um Vergebung.
Beim Mappen von längeren Wegen, welche namentlich benannt sind, wie z.B. Straßen, Flüsse, Kanäle, Bäche, o.ä. ist man in der Regel bemüht (sofern sich die Eigenschaften in deren Verlauf nicht ändern) diese zu einem durchgehenden Weg zu verbinden.
Soweit sogut, aber beim Anzeigen derer Namen geht dann irgendwann “der Schuß nach hinten los”, denn…
Wenn ich z.B. einen Fluß nehme, welcher mehrere hundert Kilometer lang und durchgehend gemappt ist, so wird in der Karte auf der gesamten Strecke nur einmal der Name angezeigt.
So jedenfalls in der Online-Karte oder eines möglichen Ausdruckes; in MapSource erhält man diese Information zwar noch wenn man mit dem Cursor darüberfährt, aber wie sieht’s im Navi aus (“habe leider keins”) ?
So denke ich wäre es günstig, wenn man diese Wege (z.B. Straßen alle 500m, Flüsse alle 2km, etc.) öfter aufspaltet um auch in einem kleineren Gebiet deren Namen zu ersehen.
Zur Strafe 10 mal mantramäßig durchbeten: “Wir mappen nicht für Renderer”.
Es ist nicht unsere Aufgabe, die Daten so zu manipulieren, dass sie ein bestimmter Renderer (es gibt ja mehrere) in irgendeiner Weise “korrekt” anzeigt. Konkret hängt es ja auch von der Zoomstufe ab, wie oft die Beschriftung angezeigt werden soll. Weiter herausgezoomt macht es ja weniger Sinn, wenn der Name dann x-fach nebeneinander angezeigt wird. Dann möchte man den Namen wieder nur einmal angezeigt haben, was aber nicht geht, wenn jedes kurze Teilstück unabhängig von den anderen beschriftet wird. LÖSUNG: der Renderer errechnet selber für jede Zoomstufe, wie oft der Name angezeigt werden soll.
Sollte es diese Einstellmöglichkeit geben, so hat sie aber allem Anschein nach noch Niemand gefunden!
Ich bete nicht zu falschen Göttern!
…denn wenn es so wäre, könnte ja Jeder mappen wozu er gerade lustig ist und der Renderer soll dann zuschauen was er beliebt daraus zu machen.
Ich mappe eigentlich mit den im Wiki festgelegten Tags, für eine Karte, welche durch einen Renderer ausgegeben wird.
…aber o.k., ich denke mal das artet nun zur Wortklauberei aus und im Endeffekt läuft doch alles auf das Selbe hinaus.
Es sollte ja auch nur eine Anregung von mir sein und was jeder für sich daraus macht bleibt, wie immer, Jedem selbst überlassen.
Also mappst du auch nur Sachen die durch den Renderer angeziegt werden?!
Außerdem gibt ja auch tausend verschiedene Renderer, bzw. Konfigurationen…
Find ich schade, denn es gibt so viel wichtige Informationen die wirklich super sinn und die halt nicht angezeigt werden. …
Bäcker, Briefkästen, mtb:scale, Ärtze, ach es gibt millionen…
Um das “Mantra” wieder mal zu erklären: Wie mappen die Wirklichkeit, so genau wie möglich. Was der Renderer daraus macht, ist sein Problem. Das hat den unbestreitbaren Vorteil, dass man die Daten - so sie wirklich perfekt sind - nicht mehr ändern braucht, um andere Darstellungen zu erreichen. Dafür braucht man nur mehr den Renderer anpassen.
So auch im vorliegenden Fall. Angenommen, die Straßennamen sind auf allen Teilstücken identisch, idealerweise sogar die Straße per Relation verbunden. Der Renderer kann daraus ableiten, dass es eine Straße ist, und die Bezeichnung optimal platzieren. Ob er das tut, ist eine andere Frage. Aber es kann jederzeit der Renderer erweitert werden - die Daten brauchen wir dann nicht mehr ändern. Würden wir jetzt, nur weil die Darstellung jetzt (zugegeben!) suboptimal ist, müssten wir sie wieder zurück ändern, sobald der Renderer entsprechend angepasst wird.
Ich würde die Diskussion nicht auf Renderer verkürzen. Schließlich enthält die OSM-Datenbank eine Menge an semantischer Information, die nicht nur für eine Anzeige sinnvoll ist. Je unabhängiger das Datenmodell von irgendeiner (graphischen oder nicht-graphischen) Anwendung ist, um so leichter können sich neue Anwendungen finden. Daher sollte man schon so genau wie möglich mappen – aber auch das Datenmodell nicht aus dem Auge verlieren.
Das Datenmodell sollte nicht nur konsistent sein, sondern auch gewisse “gute” Eigenschaften haben. Ich kann jetzt nicht genau definieren, was in Bezug auf OSM ein “gutes” Datenmodell ausmacht, aber als Analogie sei an die Normalformen von relationalen Datenbanken erinnert. (Es gibt in OSM jedenfalls Beispiele die im Sinne dieser Analogie “gut” bzw. “schlecht” sind.)
Absolute Zustimmung. Renderer werden halt am meisten angesprochen Jedenfalls: ich bin schwer dagegen, Daten mutwillig zu verschlechtern, nur damit temporär irgendeine Verbesserung in der Nutzung eintritt. Das sollen die Nutzer schon selber lösen. Die Karte ist sicherlich die wichtigste Nutzung, mit der OSM steht und fällt, aber das heißt nicht das wir die Datenqualität verschlechter müssen nur damit die Anzeigequalität steigt.
Jedenfalls: ich bin schwer dagegen, Daten mutwillig zu verschlechtern, nur damit temporär irgendeine Verbesserung in der Nutzung eintritt. Das sollen die Nutzer schon selber lösen. Die Karte ist sicherlich die wichtigste Nutzung, mit der OSM steht und fällt, aber das heißt nicht das wir die Datenqualität verschlechter müssen nur damit die Anzeigequalität steigt.