[Talk-de] Beschriftung von kurzen Straßenstücken steuern

[Tordanik]

Dirk Stöcker schrieb:
> Du übersiehst hier eine zentrale Problematik: Es gibt keine
> Standardisierung für entsprechende Render-Hints. Automatisierte
> Generierung von Karten ist ein wahrscheinlich noch lange fruchtbares
> Forschungsgebiet und die Kartengeneralisierung ist etwas, was man lange
> lernen muss, um schöne Karten zu produzieren.
> 
> Der bisherige Ansatz osmarender-spezifische Tags zu haben ist ein
> Startpunkt. Niemand hindert die anderen Renderer daran diese Tags auch
> zu nutzen. Irgendwann hat sich ein sinnvoller Satz an Renderinghinweisen
> herausgebildet und man kann über eine Standardisierung nachdenken.

Ich habe nie befürwortet, einen Hint nur dann zu verwenden, wenn er
bereits von mehreren Programmen verwendet wird oder „standardisiert“
ist. Meine Forderung nach einer für eine ganze Gruppe interessanten
Lösung lief darauf hinaus, dass man sich überlegen sollte, ob es sich
wirklich um ein prinzipielles Problem handelt. Denn wenn es andere
Renderer ohne Hint schaffen oder schaffen könnten, ist die
Wahrscheinlichkeit recht hoch, dass du lieber an deinem Programm
nachbessern solltest.

> Warum erwartest Du, dass von Anfang an eine perfekte Lösung existiert?
> So funktioniert die Welt nicht.

Zitiere bitte, woraus du schließt, dass ich das erwarte. Ich ging in
meinem ganzen Beitrag davon aus, dass man zwischen verschiedenen
bekannten Lösungsideen wählt.

> Ich würde z.B. Tags einführen, die die Anzeige gewisser Stadtnamen
> steuert. Z.B. Abhängig vom Kartenmaßstab. Es gibt Städte (und wird es
> immer geben), die aufgrund der Bevölkerungszahl eigentlich vollkommen
> unwichtig sind, aber trotzdem in einer Karte zu erscheinen haben und
> andere, die besser unterdrückt werden sollten. Auch wenn man sich noch
> so anstrengt, dass läßt sich automatisch nicht lösen.

Hab ich ja nichts dagegen. Das Problem der „Bedeutung“ eines Ortes haben
alle Renderer gleichermaßen und es lässt sich nicht algorithmisch lösen.
Hier akzeptiere ich sogar die Betrachtung als (wenn auch subjektive)
Information der Realität.

> Ein anderes Standardbeispiel ist eine Kirche. Unter Umständen ist es
> sinnvoll Autobahnen und Straßen etwas zu verschieben, um eine Kirche
> auch in kleineren Maßstäben darstellen zu können. Das kann kein Renderer
> entscheiden. Hier ist menschliches Geschick gefragt.

Das dagegen hat mit Realität wenig zu tun, die Straßen liegen nun mal in
dem, was ich als Realität verstehen würde, anders. Weit problematischer
aber: Wie es gut aussieht hängt völlig vom Rendering ab (Straßenbreite,
Symbol, Beschriftung …). Da reicht dann nicht mal ein osmarender: sobald
ich den Kartenstil selber anpassen kann, da brauche ich schon ein
osmarender-tordaniksfettestraßenstyle:move_street=1500m oder
osmarender-tordaniksatheistenstyleohnekirchen:move_street=no

Ja, ich weiß, dass man da darauf setzen kann, dass nur für eine
begrenzte Zahl von Anwendungen in größerem Umfang Tags gesetzt werden.
(Bis irgendwer seine Bots loslässt, natürlich …)

> Wenn Du in OSM nur die Realität mappen willst, dann stell Dir solche
> Rendering-Hints einfach als Teil der Realität vor - Sind sie nämlich
> auch - allerdings aufgrund gewisser gesellschaftlicher
> Wertevorstellungen, die nicht so einfach zu erkennen sind.

Ja, wenn ich Realität geeignet definiere, dann ist alles Teil der Realität…

>> Zum Schluss noch: Die Vorteile ließen sich ebenso erzielen,
>> würden die anwendungsspezifischen Tags in eigenen Datenbanken
>> gespeichert. Man kann Editoren so anpassen, dass sie nur interessante
>> Tags anzeigen, ja. Man kann sie aber auch anpassen, dass sie Daten aus
>> mehreren Quellen entnehmen und auch passend wieder hochladen. Verzichtet
>> man auf die Speicherung in der Hauptdatenbank, hätte man für diesen
>> Bereich auch ein für allemal das Problem aus der Welt geschafft, ob es
>> irgendwelche Einschränkungen (Umfang der Daten, „Relevanz“ der Anwendung
>> – de.WP lässt grüßen) dafür geben soll, was für anwendungsspezifische
>> Daten „erlaubt“ sein sollen.
> 
> Wo soll der Vorteil einer parallelen Datenbank liegen?

Gegenfrage: Willst du beliebige Mengen von Daten für beliebige
Anwendungen mit beliebig kleinem Nutzerkreis aufnehmen?

Wenn nein, dann liegt der Vorteil darin, dass er uns den
vorprogrammierten und immer wieder neu zu Diskussionen führen werdenden
Grenzziehungskonflikt erspart. Wenn ja, dann könnte der Vorteil etwas
mit Datenvolumen und Handhabbarkeit zu tun haben …

> Die Nachteile liegen auf den Hand:
> - verschiedene Logins - Nutzer können zweite Datenbank nicht ändern

Die Logins müssen keineswegs zwangsweise verschieden sein, gemeinsame
Logins sollen technisch durchaus durchführbar sein…

> - Nutzer finden zweite Datenbank überhaupt nicht

Wenn sie die im Wiki oder sonstwo das anwendungsspezifische Tag finden,
dann finden sie auch den dort hoffentlich vorhandenen DB-Hinweis. Eine
Liste von bekannten Datenbanken im Editor wäre ja auch implementierbar.

> - Daten bleiben nicht synchron

Das ist in der Tat ein Problem, wenn jemand in der Zentral-DB etwa ein
Objekt löscht und nicht mit der entsprechenden Datenbank verbunden ist.
Informationsverluste durch „Unwissende“ kann man aber auch in einer
einzigen Datenbank nur lösen, indem man dem Mapper auferlegt, bei
Änderungen (Verschiebungen etwa) die Auswirkungen auf sämtliche
anwendungsspezifischen Tags zu prüfen, sonst werden die Informationen
bei Bearbeitungen auch unbrauchbar.

Deshalb gilt unabhängig von der DB-Lösung: nicht mit Handarbeit
übertreiben. Ortsprioritäten oder die auf talk vorgeschlagene
Kennzeichnung unerwarteter Nicht-Einbahnstraßen dürften durchaus einen
Wert haben und recht wenig Aufwand verursachen. Straßenverschiebungen
(auch renderspezifische) für bessere Darstellung halte ich für
übertrieben und den Wartungsaufwand bei Bearbeitungen andere Nutzer
nicht wert.

Tordanik