Warum erscheinen diese beiden Stellwerke in unterschiedlichen Zoomstufen?
zoom=13
name=Köln-Mülheim Mf railway:ref=Mf railway=signal_box
zoom=14
building=yes name=Honrath ESTW-A railway:local_operated=no railway:ref=ESTW-A railway:signal_box=electronic railway=signal_box
Ich würde erwarten auch Honrath bereits in Stufe 13 zu sehen.
Am Donnerstag, 7. April 2016, 21:06:02 schrieb Axel Zöllich:
Das Stellwerk scheint sehr nahe an einer Tilegrenze zu liegen, ich vermute, dass es daher kommt, da der Text mit der Grenze kollidiert und deshalb nicht gerendert wird. Außerdem ist das railway:ref vermutlich ohnehin falsch.
Eike
Am Donnerstag, 7. April 2016, 23:15:02 schrieb Axel Zöllich:
Weil der Code so schlicht nicht funktioniert. Die Daten sind nur in einem Tile drin, d.h. das Tile jenseits der Grenze weiß nicht davon, das es weiterschreiben müsste.
Es gibt auch noch andere Dinge, mit denen diese Texte kollidieren können, z.B. auch Icons.
Ich gucke da bei Gelegenheit noch mal rein, ob ich noch ein anderes Problem finde.
Eike
Hi,
On 08.04.2016 07:57, Rolf Eike Beer wrote:
Wow, das erklärt einiges. Habe mich schon oft gefragt, warum völlig unvorhersehbar an manchen Stellen Labels sind und and anderen plötzlich nicht. Das ist ja wirklich unbefriedigend. Geht das denn gar nicht anders? Also dass ein Tile immer die Nachbartiles mitrendert oder so. (Ja, ich weiß, gibt dann zirkuläre Abhängigkeiten, aber muss doch irgendwie gehen) Sorry - das soll kein Meckern sein, ich bin nur ehrlich überrascht dass sowas eine Rolle spielt für die Auswahl, was gerendert wird... An welcher Stelle ist das denn? In ORM oder in node-tileserver?
Marian
Hallo,
Am Samstag, den 09.04.2016, 00:44 +0200 schrieb Marian Sigler:
mit dem Parameter "tileBoundTolerance" in https://github.com/rurseekatze/node-tileserver/blob/master/config.json kann man konfigurieren, wie viele Pixel der Nachbarkacheln mit in den Daten enthalten sein sollen. Momentan werden zusätzlich die 60px um die Kachel herum abgefragt (wie groß dieser Bereich ist, hängt von der Zoomstufe ab). Für nicht all zu lange Beschriftungen reicht das eigentlich schon, wenn man bedenkt, dass eine Kachel 512px breit ist und eine praktisch genau auf der Tilegrenze liegende Beschriftung somit maximal 120px breit sein darf, um noch gerendert zu werden.
Man kann den Parameter natürlich einfach höher setzen, aber dann werden die Kacheln größer, weil sie immer mehr Objekte der Nachbarkacheln enthalten müssen. Elegant wäre es wirklich, wenn man wie von dir vorgeschlagen praktisch die Daten der Nachbartiles mitrendert, aber dann wiederum rendert man bei jeder Kachel ja nochmal 4 oder 8 weitere Kacheln, was auch nicht wirklich performant sein dürfte.
Eine Lösung wäre vielleicht, dass man beim Erzeugen der Vektortiles nur die Objekte der Nachbartiles mit in die Kachel übernimmt, bei denen die Beschriftung eine gewisse Länge hat. Dann hätte man den Vorteil, dass nur relativ wenige Objekte der Nachbarkacheln übernommen werden müssten und man gleichzeitig nicht eine fixe Pixelgrenze angeben braucht.
Implementieren könnte man das direkt in der SQL-Abfrage, wo einmal alles im Bereich der Kachel abgefragt wird und zusätzlich nochmal alles aus einer etwas größeren Boundingbox, wo die Beschriftung aufgrund ihrer Länge die Kachelgrenze überschreiten wird. Das ist zwar auch nicht ganz perfekt, weil man an dieser Stelle eigentlich z.B. die Schriftgröße und Platzierung wissen müsste, um das korrekt zu bestimmen, aber man kann die zu erwartende Beschriftungslänge anhand der Zeichenzahl abschätzen. Man müsste dann eben für jedes Objekt aus der größeren Bbox berechnen, wie weit es von der inneren Bbox weg ist und wie lang das Label sein dürfte.
Ich muss mal schauen, wie andere Renderer diese Problematik lösen. Bei anderen Vektortilelösungen wie etwas von Mapbox dürfte ja ein ähnliches Problem auftreten.
Gruß Alex
Am Donnerstag, 7. April 2016, 21:06:02 schrieb Axel Zöllich:
Ich nehme alles zurück und behaupte das Gegenteil ;)
Wenn man sich die zugehörige JSON-Datei zu dem PNG ansieht dann findet man dort keine Hinweise auf das Stellwerk, deswegen kann es auch nicht gerendert werden:
http://tiles.openrailwaymap.org/signals/13/4261/2745.png http://tiles.openrailwaymap.org/vector/13/4261/2745.json
Eike
Hallo,
Am Samstag, den 09.04.2016, 10:29 +0200 schrieb Rolf Eike Beer:
an diese naheliegende Erklärung habe ich natürlich nicht gedacht.
Hast du dir das nochmal genauer angesehen und schon etwas herausgefunden? Eine Erklärung für dieses Verhalten habe ich nicht wirklich.
Gruß Alex
openrailwaymap@openrailwaymap.org