Name mit definierten Zeilenumbrüchen erfassen

Hallo, gibt es eine Möglichkeit, den Namen eines Objektes mit einem definierten Zeilenumbruch zu hinterlegen. Ich find das sieht unschön aus, wenn er hier (http://www.openstreetmap.org/?lat=52.342296&lon=13.107193&zoom=18&layers=M) 5 Zeilen verwendet, wenn eigentlich nur 3 notwendig wären.

lieber solltest du den renderer verbessern! in diesem falle mögen feste zeilenumbrüche sinnvoll sein. in anderen sind sie es NICHT. die darstellung wird dem renderer überlassen. ich habe auch einen geschrieben und wenn ich feststellen würde, dass “mir” vorgaben gemacht werden, würde ich die harten umbrüche vermutlich entfernen.

Das meinst du sicher nicht ernst, oder? Mapnik zu verbessern ist so eine Sache, ich habe schon mal selber wegen genau diesem Namenproblem in die Sourcen geschaut und ziemlich sofort wieder aufgegeben. Ohne Unterstützung durch einen Kenner der SW ist es auch für einen guten Programmierer unmöglich, da etwas innert vernünftiger Zeit zu machen. Zudem glaube ich nicht, dass man mittels Algorithmus jeden Fall sinnvoll abdecken kann. Also bleibt nichts anderes übrig, als mit Spezialzeichen nachzuhelfen.

Es gibt irgendwo im UTF-8 Zeichensatz ein Zeichen für “none-breakable space”, damit kannst du zumindest unnötige Umbrüche bei Leerschlägen verhindern. Da dieses Zeichen Bestandteil von UTF-8 ist, ist es völlig legal, es auch zu benutzen.

Wyo

Gary hat da wohl damit gemeint, dass man vielleicht ein Ticket für solche Sachen erstellen würde, damit die Sourcen von Grundauf gefixt werden und solch lange Namen dann generell besser dargestellt werden in Mapnik.

Naja, dadurch kann es dann aber bei anderen Renderern zu unschönen Namensdarstellungen kommen, was dann auch wieder nicht gut ist.

Wie sagt man so schön? Wir mappen nicht für einen Renderer…

Also so unschön lassen, wie es ist?

Wo wir grad beim Renderer sind. Ich find es schade, das man in OSM nicht noch weiter reinzoomen kann. Ich habe vor kurzen erst zwei unmittelbar nebeneinander stehende Briefkästen erfasst, von denen, vermutlich aufgrund der nähe zueinander nur einer dargestellt wird. Eine höhere Zoomstufe in OSM würde das “Problem” vllt. beheben oder wie ist hier der Status quo?

Naja jede weitere Zoomstufe braucht noch mal massiv mehr Rechenzeit zum berechnen und 4 mal so viel Speicher wie die Zoomstufe davor. Das kriegen wir zur Zeit definitiv nicht gestemmt :wink:

Wegen den erlaubten Zeichen hatte sich Jochen Topf schon mal auf TALK zu Wort gemeldet ob man die nicht weiter einschränken könnte. Von daher denke ich auch, dass es langfristig sinvoller ist beim Renderer anzusetzen. Klar geht das nicht von heute auf morgen, sowas braucht Zeit um sich in so eine komplexe Materie einzulesen.

Ich finde die Lösung des Renderes (Mapnik) sehr gut gelungen. Hätte man nur 3 Zeilen würden in anderen Zoomstufen vermutlich mehr Buchstaben als jetzt auf anderen Objekten liegen.

Vielleicht, es gibt aber bereits einige Ticket für die Namensgebung und dies schon seit längerer Zeit. Und solange es keine Programmierer gibt, die mit den Sourcen umgehen können, nützen auch Tickets nichts.

Das nützt auch nicht. Wie schon gesagt “Zudem glaube ich nicht, dass man mittels Algorithmus jeden Fall sinnvoll abdecken kann”.

UTF-8 ist Standard-Zeichensatz, jeder Renderer muss damit zurande kommen. Ich glaube auch nicht, dass es da überhaupt Probleme gibt.

Diese Bemerkung ist hier völlig unangebracht.

Wyo

Es geht doch nicht um den Zeichensatz, den muss der Renderer darstellen können, das ist klar. Aber wer sagt denn, dass es bei einem anderen Renderer in drei Zeilen nicht bescheiden aussieht? Außerdem wird ein Renderer den Namen wahrscheinlich garnicht darstellen, wenn er dadurch, dass er an bestimmten Stellen nicht umgebrochen werden darf, zu breit wird, was sicher auch nicht Sinn der Sache ist. Und doch, es ist angebracht. Denn es gibt ja nicht nur Renderer, für die das vielleicht interessant ist, sondern auch andere Anwendungen und man weiß nie, was man damit vielleicht kaputt macht. Z.B. vielleicht eine Suchfunktion, weil der Suchende es mit echten Leerzeichen eingibt, der name-Tag aber nonbreakables enthält.

Möglich, aber ein Algorithmus kann es auch nicht besser. Im gegebenen Fall (http://www.openstreetmap.org/?lat=52.342296&lon=13.107193&zoom=18&layers=M) dürfte das “V” am Ende keinesfalls abgetrennt werden. Jedenfalls ist der Trick mit “-” den Umbruch zu umgehen noch schlechter.

Das stimmt, aber auch dafür gibt es Lösungen, beim Suchen wird ja auch nicht zwischen gross/klein unterschieden, egal wie es geschrieben wird.

Wyo

Ich denke man sollte diese Sonderzeichen nur verwenden, wenn es einen triftigen Grund gibt. Beispielsweise in “Gleis 5 (vorne)”, da macht es Sinn zwichen “Gleis” und “5” ein nbSpace zu verwenden, da beide Teile sehr eng zusammen gehören.

Und um die Sache noch etwas spannender zu machen, gibt es im Unicode auch noch das “soft hyphen”. Das ist ein optionaler Trennstrich. Man kann also eine Trennung “vorschlagen” und derjenige, der den Text verwendet (z.B. Rendert), kann dann dort trennen.

Zum Thema Suche: Jede halbwegs brauchbare Suche sollte sowohl den zu durchsuchenden Text, als auch die Suchbegriffe “normalisieren”, also vereinfachen. Mit Unicode ist das etwas aufwendig, aber da kommt man nun man nicht drum herum. So sollten generell alle Whitespaces (Space, nbSpace, Tab, CR, LF, …) in normale Spaces verwendelt werden und beispielsweise “soft hyphens” entfernt werden.

Viele Grüsse

mdk

Ich kann mich Gary nur anschließen. WIE etwas dargestellt werden soll, ist Sache des Renderers. Wie breit so eine Textzeile sein darf hängt neben der “Schönheit” auch davon ab, wieviel Platz vorhanden ist, wie groß der Bildschirm ist, wie groß die Schrift ist usw.

Evtl. sieht es bei Mapnik auf dem PC besser aus. Evtl. sieht es dann aber auf einem Smartphone oder einem Garmin bescheiden aus oder wird garnicht angezeigt.

Dann muss der Algorithmus verbessert werden und nicht etwa die Daten so an einen Algorithmus angepasst, dass es gerade mit diesem gut aussieht.

Wie aber auch schon viele andere in diesem Thread geschrieben haben: Es gibt nicht nur einen Algorithmus, der Namen / Texte rendert, sondern ziemlich viele. Schließlich gibt es auch viele verschiedene Karten, die aus den gleichen Daten erzeugt werden. Da muss eben der zugehörige Algorithmus entscheiden, wie ein Name dargestellt werden soll. So gesehen ist der Algorithmus durchaus besser als fest von Hand vorgegebene Zeilenumbrüche, denn der kann je nach Karte ein anderer sein, speziell an diese Karte und die darin verwendeten Fonts, Schriftgrößen, Zoomstufen etc. angepasst. So eine individuelle Anpassung lässt sich nicht erreichen, wenn man die Zeilenumbrüche von Hand vorgibt.

by the way ist ein renderer auch kein word processor. will sagen, wenn ich in svg ein \n rausschreibe, muss das nicht notwendigerweise auch einen zeilenumbruch bedeuten! oder der renderer überlegt sich, dass er an der gleichen stelle eine neue zeile beginnen würde. und zack, gibt es eine leerzeile. besser wäre es, dem renderer beizubringen, wo nicht getrennt werden sollte.

ein renderer entscheidet ja darüber, wieviel platz in den beiden dimensionen zur verfügung steht und teilt den text auf. da ist der vorgegebene zeilenumbruch fast nie an der richtigen stelle. manchmal will er gar keinen, weil unter einem icon z.b. gar kein platz ist.

in letzter Zeit kommen fast täglich Fragen rein, die darauf abzielen, etwas in diesem oder jenem Renderer besser aussehen zu lassen. Und Leute wie wyo schlagen noch in die gleiche Kerbe. Zeilenumbrüche in Namen einzufügen ist einfach nur krank. Ich kann gar nicht ausdrücken, wie mich das anwidert.
Morgen beschwert sich der Nächste, weil der Zeilenumbruch in seinem Renderer nun schlechter aussieht. Und dann? Für jeden Renderer einen Tag a la name:de:mapnik?
Ein Name ist ein Name und ich sammle Geodaten und keine UTF Trennzeichen.

Naja, vielleicht hätte ich mir den Kommentar auch sparen können. Aber irgendwie empfinde ich das rumgemeckere als persönliche Kritik an der Art, wie ich mappe.

Genau das habe ich in meinem allerersten Beitrag geschrieben.
http://forum.openstreetmap.org/viewtopic.php?pid=137254#p137254

Wyo