Frecce del vento tagliate nel confine tra i tile

[edigiacomo]

Le frecce del vento sono tagliate tra un tile e l'altro. Questo effetto è molto visibile su quote alte con frecce molto lunghe, a 10m invece si nota molto meno.

Un'ipotesi è quella di creare PNG più ampi del singolo tile 256x256px, in modo che la sovrapposizione del rendering risolva questo bug.

La questione di interseca con l'eventuale produzione di più tile contemporaneamente (e.g. 4x4 o 8x8 tile) su cui si devono fare ancora delle valutazioni in termini di performance (non è stata ancora aperta issue in merito).

[dcesari]

Mi sembra un problema serio, pensavo che la divisione in tiles fosse solo qualcosa a valle del rendering. Stavo guardando un vento a 10m e in effetti ci sono delle frece tagliate anche lì, poi noto anche delle frecce doppie, come in figura: può essere un problema simile, tipo una freccia disegnata contemporaneamente in 2 tile vicine con un po' di sfasamento?

[brancomat]

Nota: la issue di riferimento sulla produzione di più tile contemporaneamente è https://github.com/ARPA-SIMC/arkimaps/issues/126

[edigiacomo]

Una possibilità che si potrebbe esplorare è quella di generare, per il solo vento, dei vettoriali al posto dei png.

Il rendering SVG con Magics ha i seguenti problemi:

1. Dimensione: leggo in https://github.com/ARPA-SIMC/arkimaps/issues/126#issuecomment-1366011075 che l'output genera un file che ha dimensioni ~10x rispetto al PNG - ma questo potrebbe impattare solo sull'occupazione del disco su server e non sulla trasmissione (grazie alla compressione con output DEFLATE)
2. Credo che le frecce sul bordo vengano comunque tagliate
3. Non so se l'output SVG è supportato da L.TileLayer https://leafletjs.com/reference.html#tilelayer

Un'alternativa da esplorare potrebbe essere quella di generare dei file ASCII contenenti i valori di intensità e direzione del vento (o di qualsiasi prodotto vettoriale, come la corrente). La produzione di un punto invece che di una linea eliminerebbe sostanzialmente il problema del taglio sul bordo dei tile. Ci sono vari aspetti da considerare in questa scelta:

• Delega all'interfaccia: il rendering dei valori è delegato all'interfaccia, che fino ad ora mostra in modo trasparente quanto prodotto da arkimaps.
• Gestione della risoluzione: arkimaps dovrebbe/potrebbe gestire i diversi livelli di zoom, interpolando con uno strumento alternativo a Magics (libsim?) i valori a seconda della risoluzione
• Formato di uscita: CSV (e.g. https://gdal.org/drivers/raster/aaigrid.html), GeoJSON (eventualmente a tile e.g. https://github.com/mapbox/geojson-vt), Vector tile (https://github.com/mapbox/vector-tile-spec), TopoJSON
• Gestione a tile/zoom: parto dal presupposto che vogliamo gestire tutto in modo omogeneo e quindi generare dei file con la stessa struttura dei tile PNG. Si potrebbe però valutare la generazione di un solo file per zoom: nel caso di ampi bounding box (e.g. scala globale), la vasta area coperta a bassi zoom potrebbe essere controbilanciata da una risoluzione (numero di punti) inversamente proporzionale. Eviterei invece di fare un unico file da usare per ogni zoom, perché in quel caso dovrebbe avere almeno la stessa risoluzione dello zoom massimo e l'interfaccia dovrebbe fare dei conti (e non solo occuparsi della presentazione) a zoom più bassi per calcolare i valori alla corrispondente risoluzione. Il ritaglio può essere fatto a monte, come nel caso dei PNG, oppure a valle (e.g. https://github.com/mapbox/geojson-vt o https://github.com/mapbox/geojson-vt o http://tilestache.org/ o con GDAL).

Considerazione a lato: l'adozione di un formato vettoriale potrebbe anche permetterne il riutilizzo per l'eventuale gestione degli osservati (#35).

Se questa strada vi sembra interessante, possiamo discuterne.