"None breakable" Leerschlag im Namen

Was meinst du mit "Wie löst man das?" Beim Eintragen in die Datenbank ist es das einzig richtige, das ganz normal einzutragen. Wenn Straßenkarten wie Mapnik, Osmarender, usw. das in einigen Zoomstufen unschön anzeigen ist das ein Bug der jeweiligen Karte.

wyo wrote:

Wenn ein Name aus mehreren Worten besteht und er nicht "Platz" hat, wird er beim Anzeigen umgebrochen (z.B. bei "Écluse No 5" wird die "5" umgebrochen). Wie löst man das?

Hallo Wyo

Indem du ein Ticket für das Problem im Trac-System erstellst.

Hintergrund, die minimale Länge ab der ein Wort umgebrochen
wird, ist sehr knapp eingestellt.
- "und" kommt auf eine eigene Zeile
- "für" bleibt zusammen mit dem folgenden Wort
Da existiert noch Optimierungs-Potential.

Für dein Beispiel kannst du natürlich 'No-5' statt 'No 5'
verwenden. Das wird dann nicht umgebrochen und ist
noch nahe genug an der echten Schreibweise.

Edbert (EvanE)

EvanE wrote:

Für dein Beispiel kannst du natürlich 'No-5' statt 'No 5'
verwenden. Das wird dann nicht umgebrochen und ist
noch nahe genug an der echten Schreibweise.

Ne, oder?! Bitte nicht irgendwas in die Datenbank falsch reinpfuschen, nur damits schoener gerendert wird.

zorque wrote:

EvanE wrote:

Für dein Beispiel kannst du natürlich 'No-5' statt 'No 5'
verwenden. Das wird dann nicht umgebrochen und ist
noch nahe genug an der echten Schreibweise.

Ne, oder?! Bitte nicht irgendwas in die Datenbank falsch reinpfuschen, nur damits schoener gerendert wird.

Schreibweisen mit oder ohne Bindestrich sind sowieso
rein willkürlich. Von daher halte ich das für vertretbar
Bindestrich/Leerzeichen gegeneinander auszutauschen,
solange der Sinn dadurch nicht verloren geht.

Bei Straßennamen sollte man solche Kompromisse
natürlich nicht machen. Da bitte an die offizielle
Schreibweise halten, sofern die zu ermitteln ist.

Bei anderen Dingen sehe ich das mit dem Namen
weniger kritisch.

Beispiel: Die "Katholische GrundSchule Am Domhof "
bezeichnet sich selbst (auf ihrer Webseite) als
"KGS Am Domhof" auf dem Zeugniss steht jedoch
"KGS AM Domhof, katholische Grundschule der Stadt Bonn"

Welcher Name darf es denn heute sein?

Aber wie immer, jeder wie er mag.

Edbert (EvanE)

EvanE wrote:

Aber wie immer, jeder wie er mag.

Ich denke es wäre sinnvoll, wenn es im Wiki abgehandelt würde. Das Bedürfnis den Umbruch an Wortgrenzen zu beschränken, oder auch das Gegenteil ein Wortteilung an bestimmten Stellen, dürfte allgemein vorhanden sein. Zudem ist ja immer noch die Frage von Trennstrich oder Nicht-Trennstrich, etc. Wie du ja selber sagts, sollten Strassennamen nicht umgebrochen werden. Wenn dies im Wiki (z.B. unter Namen:Spezialzeichen) beschrieben ist, kann es beim Rendern und beim Suchen entsprechend berücksichtigt werden.

Wyo

wyo wrote:

EvanE wrote:

Aber wie immer, jeder wie er mag.

Ich denke es wäre sinnvoll, wenn es im Wiki abgehandelt würde. Das Bedürfnis den Umbruch an Wortgrenzen zu beschränken, oder auch das Gegenteil ein Wortteilung an bestimmten Stellen, dürfte allgemein vorhanden sein. Zudem ist ja immer noch die Frage von Trennstrich oder Nicht-Trennstrich, etc. Wie du ja selber sagts, sollten Strassennamen nicht umgebrochen werden. Wenn dies im Wiki (z.B. unter Namen:Spezialzeichen) beschrieben ist, kann es beim Rendern und beim Suchen entsprechend berücksichtigt werden.

Hallo Wyo

Das Umbrechen von Namen macht (soweit ich weis)
nur Mapnik.

Straßennamen sind davon sowieso nicht betroffen,
da diese entlang dem Straßenverlauf gerendert werden.

Ob sich dafür eine eigene Wiki-Seite lohnt? Ich glaube nicht.
Das Verhalten von Mapnik ist nicht dokumentiert und wird
wahrscheinlich auch nirgends zugesichert.

Edbert (EvanE)

EvanE wrote:

Das Verhalten von Mapnik ist nicht dokumentiert und wird
wahrscheinlich auch nirgends zugesichert.

Das ist aber nicht gerade ein Gütezeichen für OSM.

Nun ich mach jetzt mal einen Bug-Report und vergesse das Ganze. Sollen sich andere darum kümmern, falls sie jemals darauf stossen.

Wyo

Generell unterstützt OSM den Unicode Zeichensatz. Dort gibt es entsprechende Zeichen:
none brakable Space: U+00A0. (gibt es auch im ISO-8859-1 als 160 = 0xA0)
Dieses Zeichen sollte als normaler Space gerendert werden, aber (hoffentlich) nicht als Trennzeichen beim Word-wrap in Mapnik benutzt werden. Norfalls dort als Bug melden.

Umgekehrt gibt es den
shy (= soft hyphen = bedingter Trennstrich) im Unicode U+00AD oder U+200B, in ISO-8859-1 als 173 = 0xAD.
Dieses Zeichen sollte in einem Wort nicht gerendert werden, aber (hoffentlich) als Trennzeichen beim Word-wrap benutzt werden. Wenn dort getrennt wird, sollte das Shy beim ersten Teil bleiben und als Trennstrich gezeichnet werden.

Generell gilt aber auch hier: Die Konsumenten der Daten entscheiden, was gemacht wird. Ob Mapnik (oder andere) die Daten korrekt interpretieren, ist also eine andere Frage.

Das wär doch DIE Lösung die mdk präsentiert hat. Dann bräuchten die Editoren nur eine Funktion in ein Menü packen "Leerzeichen nicht umbrechen" oder ähnliches, wenn man das entsprechende Leerzeichen markiert und die Funktion benutzt wird es einfach durch den none brakable Space ersetzt.
Ansonsten dürfte es für Renderer nämlich schwer werden zu unterscheiden wo sie umbrechen dürfen und wo nicht. Denn generell find ich das Verhalten von Mapnik gar nicht so schlecht mit dem automatischen Umbruch.

Edit: Es sollte demnach aber natürlich auch Regeln geben die festlegen wann so ein none brakable Space gesetzt werden darf, sonst kann die Übersichtlichkeit der von Renderern erstellten Bilder ziemlich negativ beeinflusst werden.

Grundsätzlich kann man die Zeichen "normal" eingeben (ohne Anpassung der Editoren). Wobei es je nach Bertiebssystem (bzw Windowsmanager) unterschiedliche Methoden gibt.

Beispiele für non-breaking space: http://en.wikipedia.org/wiki/Non_breaka … ry_methods

Ich halte es für keine gute Idee, solche Sonderzeichen einzubauen. Wenn ein Renderer an einer unschönen Stelle umbricht, ist das halt so. Aber bei Verwendung solcher Sonderzeichen kann man nie sicher sein, was man damit kaputt macht. Spontan fällt mir ein, dass dann wahrscheinlich Nominatim Probleme haben wird, entsprechend getaggtes zu finden.

mdk wrote:

Grundsätzlich kann man die Zeichen "normal" eingeben (ohne Anpassung der Editoren). Wobei es je nach Bertiebssystem (bzw Windowsmanager) unterschiedliche Methoden gibt.

Beispiele für non-breaking space: http://en.wikipedia.org/wiki/Non_breaka … ry_methods

Damit lieferst du dir doch schon selbst das Argument für eine Anpassung des Editors. Nur weil es grundsätzlich überall IRGENDWIE geht, heisst das noch nicht, dass es auch Anwenderfreundlich ist. Allein für Windows und Unixoide gibt es ja schon jeweils 3 unterschiedliche Methoden. Ich wette mit dir, dass mindestens 80% der Mapper nicht weiss wie sie so ein none brakable Leerzeichen eingeben weil sie es nie gebraucht haben bisher und die wenigsten was mit Zeichensätzen anfangen können.

Was errt anspricht ist natürlich wieder ein anderes Problem, man weiss halt wirklich nicht welche Auswirkungen das haben wird.
Edit: Wobei diese Auswirkungen sicher auch nicht schlimmer sein werden als die der Methode Bindestriche statt Leerzeichen ein zu setzen nur um den Umbruch zu vermeiden.

S-A-L wrote:

Wobei diese Auswirkungen sicher auch nicht schlimmer sein werden als die der Methode Bindestriche statt Leerzeichen ein zu setzen nur um den Umbruch zu vermeiden.

Das ist genau das Problem, die einen kümmert der Umbruch nicht, die anderen fügen Bindestriche ein, die dritten nehmen den geschützen Leerschlag, die vierten kürzen zusammen etc. Mapnik kann es egal sein, angezeigt wird was im Namen steht. Nominatim hingegen muss mit diversen Methoden abfinden, das sollte doch nicht sein.

Wyo

Ja, aber ich gehe davon aus, dass Bindestriche und Leerzeichen zu den Zeichen gehören, die Programmierer in ihre Überlegungen mit einbeziehen. Wenn wir aber das ganze Repertoire an Spezialtrennzeichen nutzen, kann das schiefgehen. Sicher könnte man argumentieren, dass man sie Nominatim ja beibringen kann. Aber es wird immer ähnliche Anwendungen geben und da können dann eben Probleme auftreten, die auch schwer zu entdecken sein dürften. Bei Renderern ist das Problem dagegen recht gut zu erkennen und wenn ein Programmierer da höhere Ansprüche an die Umbrüche hat, muss er eben eine komplexer Logik dafür entwerfen.

naja, er soll mal für garmin und/oder Mapnik und/oder Osmarender taggen... dann schaue ich mir das ganze mal an. wenn es mir nicht passt, tagge ich es für Navit um damit die Zeilenumbrüche dort richtig gemacht werden, und hoffe, dass mein OpenTom-Kumpel demnächst nicht reinschaut und für seine Karten umtaggt...

Ich würde das Problem pragmatisch angehen:

1) OSM verwendet Unicode, folglich sollten alle Unicode-Zeichen zulässig sein (Ausser man definiert eine Blacklist von verbotenen Zeichen)
2) Wenn bestimmte Applikationen (Renderer, Nominatim, ...) Probleme haben, dann sollten die Applikationen angepasst werden und nicht die OSM-Daten.
3) Wenn man die Mapper auf bestimmte Möglichkeiten hinweisen will (Keys, Values, Sonderzeichen, ...), dann kann man das in diesen Editoren einbauen und/oder im Wiki dokumentieren.
4) Ansonsten lebt OSM sehr gut mit Daten, die nicht überall "richtig" oder "vollständig" interpretiert werden.

mdk