28 gennaio, 2013 | di

indici_tasselloLa cartografia digitale è ormai da tempo invasa da milioni di tasselli. I layer di Virtual Earth (che sono vecchio!), OpenStreetMap, Yahoo! Maps, Google Maps, ecc. sono da tempo distribuiti a pezzetti da 256×256 pixel e poi ricomposti nei nostri browser. Le modalità con cui la cosa viene realizzata sono “abbastanza” standard; se si prova però ad approfondire un po’, si scopre ad esempio una grande varietà nel definire l’indice numerico associato ad un dato tassello, di una certa zona del mondo, ad uno specifico livello di zoom. La mia amata/odiata Sicilia ad esempio, a livello di ingrandimento “6″, la posso richiamare nei modi diversi che vedete qui accanto, per tre dei più diffusi indici di tassellamento. Per approfondire il tema vi consiglio di partire da qui.

Nel tempo queste mattonelle cartografiche sono aumentate a dismisura e ce le troviamo anche in tasca. Penso ai nostri smartphone e al fatto che la quasi totalità delle basi cartografiche delle applicazioni che installiamo in questi sono distribuite a tasselli.

E nel prossimo futuro la diffusione sarà ancora più pervasiva, in quanto passeranno dall’essere consultati quasi esclusivamente tramite servizi/server web, all’essere letti direttamente da un file residente sul nostro terminale. Un esempio per tutti è quello del GeoPackage, un formato standard che l’OGC sta definendo, in cui le basi raster potranno essere archiviate proprio a tasselli. Un po’ come rasterlite di Sandro Furieri, che credo sia in qualche modo lo scheletro portante di questo nuovo formato OGC.

I tasselli sono talmente tanti che ormai spesso trovo negli hard-disk, pen-drive USB, DVD (come sono vecchio!), schede SD, ecc. quelle strane cartelle a loro volta suddivise in decine e decine (nel caso migliore) di sottocartelle, tipiche della struttura di archiviazione su file system di basi dati tassellate e piramidate.

Proprio per questo ho pensato di scrivere un articolo su come accedere ad un archivio cartografico di questo tipo, che in qualche modo è il complementare ad un altro scritto nel lontanissimo 2008 e in cui viene illustrato come tassellare un’immagine.

Come accedere ad un archivio cartografico a tasselli e ricomporlo in un unica immagine georeferenziata?

In sé la cosa sembra ovvia, in quanto si tratta di formati file leggibili da qualsiasi terminale con qualsiasi sistema operativo: parliamo infatti nella stragrande maggioranza dei casi di .jpg e .png. Sfoglio le cartelle, faccio doppio click su una delle immagini e le visualizzo in un attimo. E dove è finita l’informazione geografica?

Se le apro infatti con un visualizzatore di immagini è normale che le uniche coordinate riconosciute siano i pixel, ma se provate ad aprire lo stesso tassello con una applicazione GIS, il risultato non cambia. L’informazione geografica infatti non è presente nemmeno in qualche tag nascosto internamente ai file e quindi non può essere letta. Per assurdo tutti i tasselli sembrano sovrapposti nello stesso punto della terra, ad una sola risoluzione.

L’arcano si risolve proprio nella lettura della struttura della cartella in cui sono archiviati e quindi nella conoscenza dell’indice utilizzato per generare tutti i pezzetti di mondo alle varie scale di ingrandimento. Data infatti una certa modalità di tassellamento, ogni punto della terra è associato ad una certa tessera di questo enorme mosaico, per un certo livello di zoom.

strutturaMa sporchiamoci un po’ le mani. Nell’immagine accanto una cartella di output di un tassellamento, con le sue sottocartelle, che potete scaricare da qui. Se la si sfoglia un po’ e si provano ad aprire i singoli file che troviamo all’interno delle varie cartelle, è evidente che quello che varia per ogni tassello è l’ingrandimento e/o l’area della Terra rappresentata. Posizione e zoom, ovvero x, y e z.

In questo esempio, ed è facile verificarlo in modo empirico, il primo livello di sottocartelle è legato all’ingrandimento: dalla cartella “0″ con la risoluzione più bassa a quella “4″ con quella più alta. All’interno di queste invece le eventuali sottocartelle rappresentano spostamenti lungo l’asse x. Nella figura di sopra quindi le cartelle “NE2_50M_SR_W\1″ e “NE2_50M_SR_W\1\1″ contengono, per il livello di zoom “1″, porzioni di Terra affiancate. La variazione lungo l’asse y è invece resa, per ogni cartella, dal nome del file: il tassello “1.png” sta a Nord di quello “0.png”.

Nella figura sottostante ho schematizzato la cosa, per rendere ancora più leggibile e chiara questa struttura.

dettaglio_web

Conoscere tutto questo ovviamente non basta a posizionare queste immagini nello spazio, ma soltanto in modo relativo. Per fortuna però il tassellamento viene fatto secondo standard, magari diversi, ma definiti. Quindi se conosciamo (o riconosciamo) lo standard con cui sono state generate le nostre tessere, basterà essere in possesso di un client che sappia leggere questo standard e queste verranno posizionate correttamente nello spazio cartografico. Un po’ come quando accediamo ad un servizio WMS.

La cartella di esempio che sto usando per questo esercizio contiene al suo interno (per fortuna c’è quasi sempre qualcosa di simile) il seguente file .xml.

< ?xml version="1.0" encoding="utf-8"?>
<tilemap version="1.0.0" tilemapservice="http://tms.osgeo.org/1.0.0">
<title>NE2_50M_SR_W</title>
<abstract></abstract>
<srs>EPSG:900913</srs>
<boundingbox minx="-85.05112878000000" miny="-180.00000000000000" maxx="85.05112878000000" maxy="179.99871994141003"></boundingbox>
<origin x="-85.05112878000000" y="-180.00000000000000"></origin>
<tileformat width="256" height="256" mime-type="image/png" extension="png"></tileformat>
<tilesets profile="mercator">
<tileset href="0" units-per-pixel="156543.03390000000945" order="0"></tileset>
<tileset href="1" units-per-pixel="78271.51695000000473" order="1"></tileset>
<tileset href="2" units-per-pixel="39135.75847500000236" order="2"></tileset>
<tileset href="3" units-per-pixel="19567.87923750000118" order="3"></tileset>
<tileset href="4" units-per-pixel="9783.93961875000059" order="4"></tileset>
</tilesets>
</tilemap>

E’ un piccolo tesoro che ci dice quasi tutto della struttura a tasselli che stiamo analizzando:

  • la specifica sul formato di tassellamento, ovvero il TMS 1.0 (Tile Map Service) di OSGeo;
  • lo Spatial Reference System usato;
  • il Bounding Box;
  • l’origine del mosaico dei tasselli;
  • formato e dimensioni dei tasselli;
  • e la risoluzione per ogni livello di zoom.

Non ci resta che trovare un client compatibile con lo standard TMS e provare a leggere questa struttura dati. La scelta va ancora una volta verso il Victorinox delle librerie spaziali, ovvero GDAL/OGR. Sfruttando infatti i minidriver di GDAL, descritti in fondo nella pagina di accesso ai servizi WMS, è possibile accedere direttamente a dati esposti in TMS; sia come che su file system. Prima è però necessario definire un file di configurazione, come descritto nella documentazione di cui sopra e di cui si riporta a seguire un esempio, basato sui dati che sto usando per questo post.

<gdal_wms>
<service name="TMS">
<serverurl>
file://C:/tmp/NE2_50M_SR_W/${z}/${x}/${y}.png
</serverurl>
</service>
<imageformat>image/png</imageformat>
<datawindow>
<upperleftx>-20037508.34</upperleftx>
<upperlefty>20037508.34</upperlefty>
<lowerrightx>20037508.34</lowerrightx>
<lowerrighty>-20037508.34</lowerrighty>
<tilelevel>4</tilelevel>
<tilecountx>1</tilecountx>
<tilecounty>1</tilecounty>
</datawindow>
<projection>EPSG:900913</projection>
<blocksizex>256</blocksizex>
<blocksizey>256</blocksizey>
<bandscount>3</bandscount>
<maxconnections>10</maxconnections>
<cache></cache>
</gdal_wms>

Il file contiene, in modo differente, quasi le stesse informazioni descritte prime per il file .xml. Tra queste:

  • il tipo di servizio - <service name>
  • l’indirizzo per accedere ai dati - <serverurl>
  • il formato immagine della sorgente dati - <imageformat>
  • il Bounding Box - <upperleftx>, <upperlefty>, …
  • il livello di Zoom con la risoluzione più alta, che ricavo proprio dal file.xml di sopra - <tilelevel>
  • lo Spatial Reference System - <projection>
  • la dimensione in pixel dei tasselli - <blocksizex>, <blocksizey>

Il valore del parametro ServerUrl – ovvero l’indirizzo della sorgente dati – è di solito quello di un servizio web con una forma di questo tipo: http://myserver.it/NE2_50M_SR_W/${z}/${x}/${y}.png.

Nel caso descritto i dati sono su un hard-disk di un PC e quindi, l’accesso non è in HTTP ma secondo lo schema URI di accesso a file: file://C:/tmp/NE2_50M_SR_W/${z}/${x}/${y}.png (in questo esempio la cartella dei dati è all’interno di “C:\tmp”).
Nell’URI è necessario indicare come è realizzata, in termini di struttura e nomi dei file, la mappatura di x, y e z. Nel caso in esame abbiamo visto che è resa come z/x/y.png, e cosi è stata riportata nel file di configurazione. Bisogna soltanto fare attenzione alla sintassi che prevede l’utilizzo di alcuni caratteri speciali.

Creato il file di configurazione e salvato con nome (ad esempio “input.txt”), non resta che provare a leggere i dati. Il primo passo, un po’ per fare debug è aprire la shell e digitare:

gdalinfo input.txt

Come risultato, se tutto è correttamente configurato, si otterrà:

Driver: WMS/OGC Web Map Service
Files: input.txt
Size is 4096, 4096
Coordinate System is:
PROJCS[\"Google Maps Global Mercator\",
    GEOGCS[\"WGS 84\",
        DATUM[\"WGS_1984\",
            SPHEROID[\"WGS 84\",6378137,298.257223563,
                AUTHORITY[\"EPSG\",\"7030\"]],
            AUTHORITY[\"EPSG\",\"6326\"]],
        PRIMEM[\"Greenwich\",0,
            AUTHORITY[\"EPSG\",\"8901\"]],
        UNIT[\"degree\",0.01745329251994328,
            AUTHORITY[\"EPSG\",\"9122\"]],
        AUTHORITY[\"EPSG\",\"4326\"]],
    PROJECTION[\"Mercator_2SP\"],
    PARAMETER[\"standard_parallel_1\",0],
    PARAMETER[\"latitude_of_origin\",0],
    PARAMETER[\"central_meridian\",0],
    PARAMETER[\"false_easting\",0],
    PARAMETER[\"false_northing\",0],
    UNIT[\"Meter\",1],
    EXTENSION[\"PROJ4\",\"+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext  +no_defs\"],
    AUTHORITY[\"EPSG\",\"900913\"]]
Origin = (-20037508.340000000000000,20037508.340000000000000)
Pixel Size = (9783.939619140624900,-9783.939619140624900)
Image Structure Metadata:
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  (-20037508.340,20037508.340) (180d 0' 0.00\"W, 85d 3' 4.06\"N)
Lower Left  (-20037508.340,-20037508.340) (180d 0' 0.00\"W, 85d 3' 4.06\"S)
Upper Right (20037508.340,20037508.340) (180d 0' 0.00\"E, 85d 3' 4.06\"N)
Lower Right (20037508.340,-20037508.340) (180d 0' 0.00\"E, 85d 3' 4.06\"S)
Center      (   0.0000000,   0.0000000) (  0d 0' 0.01\"E,  0d 0' 0.01\"N)
Band 1 Block=256x256 Type=Byte, ColorInterp=Red
  Overviews: 2048x2048, 1024x1024, 512x512, 256x256
Band 2 Block=256x256 Type=Byte, ColorInterp=Green
  Overviews: 2048x2048, 1024x1024, 512x512, 256x256
Band 3 Block=256x256 Type=Byte, ColorInterp=Blue
  Overviews: 2048x2048, 1024x1024, 512x512, 256x256

Siamo riusciti a leggere correttamente le informazioni sui nostri dati e non abbiamo avuto nessun errore. A questo punto il comando per la ricomposizione in un’unica immagine georeferenziata è la cosa più ovvia, è gdal_translate:

gdal_translate input.txt output.tif

L’output sarà un unico file geotiff, Mission Accomplished!

Questo ovviamente è un caso semplice, costruito in modo che sia replicabile e didatticamente valido. Nella pratica quotidiana è tutto un po’ più complicato, ma leggendo i riferimenti indicati nell’articolo, documentandosi un po’, sarà possibile replicare la cosa con i propri dati.
La carta di base da cui ho generato i tasselli (che poi ho ricomposto) è la bella “Natural Earth II with Shaded Relief and Water“. E’ rilasciata sotto pubblico dominio e scaricabile da qui.

Con i minidriver di GDAL/OGR si possono fare tante altre cose, come accedere e quindi (volendo) scaricare, i tasselli di Bing Maps e Google Maps, facendo però la giusta attenzione ai termini legali imposti. Inoltre il file di testo di input creato sopra, può essere trascinato in drag & drop su Quantum GIS e visualizzato pochi secondi dopo. Questo sempre grazie all’esistenza degli standard e di GDAL/OGR.

Questo articolo diverrà magari presto “superato” proprio perché l’invasione dei tasselli sarà probabilmente peggiore di un attacco zombie, e saranno pertanto sviluppate modalità di accesso, procedure e interfacce ancora più semplici e trasparenti. Il fatto di poter accedere al basso livello descritto in questo articolo, offre comunque una potenza e una libertà di impieghi che difficilmente si potrà ottenere tramite strumenti di livello più alto.

In ultimo ringrazio Lorenzo Perone che mi ha dato gli stimoli per mettere in linea questi pensieri e questo processo.

16 maggio, 2012 | di

Subito due premesse: la prima è che  lo stupido  titolo fa riferimento alle pecore, la seconda è che questo post avrebbe dovuto essere pubblicato nella categoria “Up, close and personal” che da tempo abbiamo rimosso.

Uso Geopararazzi da tempo, e ho il privilegio e il piacere di conoscerne l’autore: Andrea Antonello. Sino a pochi giorni fa era però soltanto una conoscenza virtuale, ma il 27 aprile scorso è venuto trascorrere tre giorni di relax nella mia Palermo, spesi in visite lampo tra i numerosi beni culturali e ambientali di questa terra.
Una compagnia fissa è stata la ricotta: abbiamo iniziato con le muffolette, continuato con le cassatelle e chiuso con sfince di San Giuseppe e cannoli.

A Palermo (ed in quasi tutta la Sicilia) la ricotta è (quasi) soltanto di pecora. Credetemi è qualcosa di superiore, senza rivali nella sua categoria.

Io e Andrea siamo dei nerd geek  normalmente “incollati” davanti al PC, ma il molto bello, il molto buono e dei strani superpoteri hanno preso il sopravvento e in questi giorni insieme siamo stati lontani da qualsiasi computer e abbiamo parlato di geomatica soltanto 10 minuti. Eravamo in macchina verso la “Riserva dello Zingaro”:

Andrea B. :  Sarebbe bello in Geopaparazzi poter inserire come mappa di sfondo una propria base cartografica (una carta tecnica, una porzione di ortofoto, ecc.). Non dovrebbe essere difficile replicando il meccanismo di accesso ai tasselli dei layer ufficiali (OpenStreetMap, CycleMap, CloudMade, ecc.).
Andrea A. : Ci penso da tempo, ed avevo chiesto a tizio caio di mandarmi dei dati per fare un test, ma non li ho ancora ricevuti.
Andrea B. : Allora te li mando io

Un software come questo, utile per fare rilievi sul campo con uno smartphone, deve avere la possibilità di inserire come sfondo una proprio layer di sfondo; per ragioni legate ad una migliore qualità di rappresentazione, ad una maggiore risoluzione, ad un temastismo più adeguato e ad una data di aggiornamento più recente delle basi scelte.

Rientrato Andrea a Bolzano, gli mando subito il link al servizio pubblicato in tile caching dal S.I.T.R. Infrastruttura Dati Territoriale della Regione Siciliana (segnalatomi da Agostino Cirasa), e gli propongo di fare dei test con questo.
Stordito piacevolmente dalla ricotta ancora in circolo nel suo sangue, riesce subito ad ottenere un risultato. Con lui tutto sembra sempre molto facile, perché è una vera cintura nera di sviluppo in Java di applicazioni spaziali, ed è uno che ci mette sempre molta energia e positività.

Facciamo allora subito altri test, a partire da basi a sua disposizione ed abbiamo però qualche piccolo problema.
OpenStreetMap, Google Maps, Bing maps, Yahoo! maps e molti altri provider cartografici pubblicano i propri dati utilizzando meccanismi di tile caching che sfruttano la stessa proiezione (EPSG:3785), lo stesso taglio di tasselli, la stessa risoluzione e la stessa definizione dei livelli di zoom. L’unica differenza è nel modo in cui vengono indicizzati, e le chiamate dei client devono tenerne conto, in modo da scaricare il tassello corretto per quella zona a quel dato livelo di zoom. Il nostro problema nasceva banalmente proprio da qui: avevo generato dei tasselli secondo lo schema OGC, mentre Geopaparazzi se li aspetta secondo lo schema OSM.
Per fortuna è soltanto una questione di indici, e analizzato e compreso insieme con Andrea il problema, lui ha subito scritto il codice necessario a fare dialogare il suo software con lo schema OGC (e con altri), e finalmente abbiamo iniziato a visualizzare le nostre basi basi come layer di sfondo.

Come vi dicevo Andrea è bravo ed energico, ed in poche ore ha creato anche un motore per generare comodamente dalla GUI di uDig – tramite i JGrasstools - cartelle di tasselli da usare come source per Geopaparazzi, ed ha scritto il codice per abilitarne l’accesso anche da uDig.
Tutto questo lo vedrete nella prossima versione di Geopaparazzi e questo vale soltanto come post di annuncio; al rilascio ne daremo conto anche qui, con dei contributi più “tecnici” e pratici.

E’ stata la prima volta che ci siamo messi in gioco insieme su qualcosa di tecnico, ed è stata un’esperienza umana e professionale molto bella. Non abbiamo fatto nulla di straordinario, ma ci siamo resi conto che unendo competenze e passione si ha come la sensazione di avere dei superpoteri.
L’ultima sera a Palermo l’abbiamo passata guardando The Avengers al cinema, e qualche giorno fa Andrea mi ha detto che “guardare fumetti insieme è qualcosa di molto intimo”. Per un po’ di tempo in chat lo chiamerò Tony (il ragazzo prodigioso è lui) e lui, rivolgendosi a me, Bruce!

 

Andrea ha scritto la sua versione del post nel suo blog.

 

22 aprile, 2008 | di

In un post recente, ho scritto di alcune delle modalità di pubblicazione online di cartografia digitale. Ne sono seguiti dei commenti interessanti, ed alcune email con richieste di consigli e di approfondimento. L’argomento  mi è sembrato “caldo”, e credo valga la pena alimentarlo ulteriormente.

Su un blog che vi consiglio di leggere – thematicmapping blog – ho scoperto dell’esistenza di GDAL2Tiles, un software a riga di comando che consente di pubblicare -rapidamente e con efficacia – una carta raster nelle seguenti modalità: Google Maps, OpenLayers and Google Earth. E’ uno strumento incluso in GDAL/OGR 1.5.0, e quindi anche nell’ultimo FWTools.

image_pyramid Il lavoro che fa GDAL2Tiles è quello di leggere un’immagine georeferenziata, e suddividerla in tasselli da 256 x 256 pixel, con una struttura a piramide (il nome del pacchetto è in qualche modo descrittivo della funzione che svolge). In altre parole a partire da una raster, ne vengono generate diverse a risoluzioni decrescenti, che vengono suddivise in sezioni da 256 pixel (vedi figura).

Il tassellamento e la piramidazione sono molto efficienti per distribuire raster sul web, in quanto l’immagine potrà essere visualizzata direttamente alla risoluzione adatta al livello di zoom attivo, e verranno scaricati soltanto i tasselli dell’area che stiamo osservando a video. E’ il meccanismo che sta dietro al motore di Google Maps e a quello dei maggiori provider di cartografia online.

Andiamo alla parte pratica e proviamo a mettere online una delle fantastiche immagini presenti su Natural Earth II. Si tratta di file (qui sotto un esempio) che rappresentano la terra, così come sarebbe senza l’influenza dell’uomo (immaginate Parigi coperta da una foresta temperata …); una rappresentazione del pianeta, precedente all’era moderna.

natural_earth

Per il mio esempio ho scaricato la tavola denominata “Ocean with layered depth tints“.

La prima cosa che ho fatto è stata georeferenziarla. Conosco le coordinate dei 4 vertici della tavola, ho FWTools installato, e dalla shell FWTools lancio il seguente comando:

> gdal_translate -a_srs EPSG:4326 -gcp 0 0 -180 90 -gcp 16200 0 180 90
-gcp 16200 8100 180 -90 NE2_modis3.jpg NE2_modis3.tif

gdal_translate è una delle utility presenti in FWTools; questo il significato dei parametri usati:

-a_srs per assegnare il corretto sistema di coordinate (EPSG:4326)
-gcp per assegnare i vari punti di controllo (prima le coordinate in pixel, e poi quelle del sistema di coordinate scelto)

A partire dalla jpeg scaricata, ho creato un tif georeferenziata, assegnando come punti di controllo i 4 vertici della carta.

Dovrò adesso processare l’immagine con gdalwarp:

> gdalwarp -t_srs EPSG:4326 NE2_modis3.tif NE2_modis3_4326.tif

-t_srs è il parametro per assegnare il sistema di coordinate.

La mia immagine di partenza è di 16200  x 8100 pixel; GDAL2Tiles la tassellerà e la piramiderà. Ogni tassello che andrò a generare sarà di  256 x 256 pixel. I livelli di piramidazione, corrispondenti ai livelli di zoom possibili, rispecchieranno lo schema della tabella sottostante.

Livello di Zoom

Dimensione immagine

Tasselli

Numero totale di tasselli

1

512 x 256

2 x 1

2

2

1024 x 512

4 x 2

8

3

2048 x 1024

8 x 4

32

4

4096 x 2048

16 x 8

128

5

8192 x 4096

32 x 16

512

6

16384 x 8192

64 x 32

2048

7

32768 x 16384

128 x 64

8192

Per il mio esempio mi “accontenterò” di un livello di zoom massimo pari a 5 e, prima di dare in pasto il mio file a GDAL2Tiles, ne ridurrò le dimensioni di conseguenza:

> gdal_translate -outsize 8192 4096 NE2_modis3_4326.tif
NE2_modis3_4326_5.tif

-outsize per specifcare la larghezza e l’altezza dell’immagine di output

Non mi resta che “passare” a GDAL2Tiles, l’ultimo file generato:

> gdal2tiles -title \"Pubblicare una Raster\" -publishurl
http://www.nostroserver.org/maptiles/ -v 
NE2_modis3_4326_5.tif cartella_di_output

-title per dare un titolo al progetto
-publishurl per definire l’url delle mappe che pubblicheremo
-v per avere un output “verboso” del comando, e leggere a video il dettaglio di tutte le operazioni eseguite da GDAL2Tiles

L’output del processo sarà una cartella con il seguente contenuto:

  • una sottocartella per ognuno dei livelli di piramidazione (in ognuna di queste diverse altre sottocartelle con i vari tasselli da 256 x 256 pixel)
  • un file denominato “openlayers.html”, ovvero un’interfaccia web basata su OpenLayers
  • un file denominato “googlemaps.html”, ovvero un’interfaccia web basata su Google Maps
  • un file denominato “tilemapresource.xml”, ovvero lo schema della struttura dei tasselli di mappa
  • un file denominato “cartella_di_output.kml”, che ci consentirà di visualizzare in Google Earth l’immagine processata (vedi figura sotto)

Bisognerà fare l’upload di tutti i file creati da GDAL2Tiles, all’interno della cartella specificata sopra con il parametro -publishurl, e testarne infine il risultato.

Qui potete testare la visualizzazione della mappa in OpenLayers, qui in Google Maps e qui in Google Earth.

google_earth

Il file con l’interfaccia basata su OpenLayers ha bisogno di una patch. Qui il file con la patch applicata.

Un bravo webmaster è in grado di portare a termine questa procedura, senza sapere nulla di cartografia digitale? Probabilmente si, ma magari soltanto in modo meccanico e pertanto non saprà applicarla ad esempi differenti da quelli descritti (immaginate di partire da un 25000 IGM).

Non ci si improvvisa cartografi online, e bisogna sempre documentarsi. Strumenti come questo fanno venire la voglia di farlo e consentono una più rapida valorizzazione e diffusione di queste tematiche. E’ per questo che mi piace GDAL2Tiles.


TANTO non rappresenta una testata giornalistica ai sensi della legge n. 62 del 7.03.2001, in quanto non viene aggiornato con una precisa e determinata periodicita'. Pertanto, in alcun modo puo' considerarsi un prodotto editoriale.