[openrailwaymap] Tile-Rendering

[Alexander Matheisen]

Hallo,

Am Samstag, den 09.04.2016, 00:44 +0200 schrieb Marian Sigler:
> Hi,
> 
> On 08.04.2016 07:57, Rolf Eike Beer wrote:
> > Am Donnerstag, 7. April 2016, 23:15: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.
> > > 
> > > Warum sollte der Text dann nicht gerendert werden? Ein Hälfte da,
> > > die andere
> > > dort.
> > 
> > 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.
> 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?

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openrailwaymap.org/archives/openrailwaymap/attachments/20160409/9ec62c78/attachment.sig>