Va bene,
cerco di spiegarti come la vedo io su questo formato GeoTiff.
Che premetto a me piace comunque.
Il GeoTiff è un TIFF con dei tag metadati customizzati per contenere le informazioni geografiche.
Per questo un geotiff viene aperto anche da un normale viewer di Tiff che niente sa' del geotiff.
Perhce' il formato binario è TIFF.
Il tiff memorizza un pixel = una cella.
Poi ci sta la sovrastruttura dei tags GEO che gli dice che una cella misura X di lunghezza e Y di larghezza in metri o unita similare. Definisce Datum, Ellissoide, etc...
Mi rendo conto che la differenza puo' apparire insignificante , ma da un punto di vista funzionale non lo è.
Perhce' questo impatta su tutta una serie di operazioni e a che livello farle.
Piramidi, generalizzazioni, etc...
Infatti, questa cosa viene gestita come una sovrastruttura rispetto al formato nativo che è TIFF, tutte le operazioni che devon tenere conto di dove sta' un pixel per decidere se fonderlo, mantenerlo , approssimarlo, devono essere compiute livello piu' alto se si vuole tenere conto della sua posizione nello spazio, e non a livello basso. dove tratterebbero tutto come fossero dei quadratini di dimensione pixel.
Quindi:
il TIFF considera la cella quadrata.
Poi , arriva la sovrastruttura e dice che quando si rappresenta la X deve essere raddoppiata.
Questo pero' si vedrà solo su un sistema geografico che supporta i tags GeoTiff.
Intendiamoci non sto' dicendo che il formato GeoTiff non va bene .
Anzi mi piace molto perche' ha avuto una idea intelligente.
Ma non è un formato che nasce naticamente per supportare cose di questo genere.
I campi metadata del Tiff dovevano servire per veicolareinformazioni accessorie,
ovvero per dire i DPI della scansione, la data di nascita, il proprietario, etc...
Nel caso del GeoTiff hanno avuto l'idea di definire alcuni tags con dei nomi ben precisi.
In tali campi ci hanno messo tutto cio' che serviva per una georefer.
Per fare un parallelismo di esempio:
Concettualmente è come avessimo un formato chiamato
GeoShapefile,
in cui è previsto che nel file SHP ci sia la geometria sempre memorizzata in falsa origine con centro del sistema di riferimento a 0 .
E poi si demandasse a un quarto file, che magari casualmente chiamiamo ".xml" (metadato) in cui
sia contenuto anche l'informazione di dove collocare l'origine degli assi , il datum, l'ellissoide, oltre a proprietari, e data di creazione.
Se apri lo shapefile con un sistema gis che NON supporta questo teorico formato GeoShapefile lo vedi a coordinate 0, se lo apri con un sistema Gis che supporta il GeoShapefile lo vedi cascare sulla Toscana.
Ovvio che alla fine il risultato è lo stesso, ma se vai a fare intersezioni, puoi non avere i medesimi risultati.
Perche' i sistemi di riferimento non sono lineari e una cosa che si interseca se sei in un mondo in falsa origine, potrebbe non intersecarsi piu' una volta che applichi una trasformazione che lo sposta e lo dilata.
Quindi sei costretto a spostare tutti i calcoli a dopo aver applicato la trasformazione e questo comporta piu' inefficienza.
Andrea.
On 19/10/2013 01:58, stefano campus wrote:
scusa andrea, non ho capito...
le caratteristiche del tiff sono scritte nell'header del file stesso, no?
quindi se ho capito bene, una proiezione del grid dovrebbe lasciare
inalterato quanto contenuto nell'header?
mi spieghi per favore?
s.
--
View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Formato-open-per-i-grid-tp7584135p7584214.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.
_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666 iscritti al 22.7.2013