[Gfoss] DDL Software libero, dati, formati e contenuti aperti in Trentino

[a.furieri a lqt.it]

per prima cosa approfitto per rilanciare ancora
una volta il documento con le linee guida di
GFOSS.it sugli Open Data Geografici:
http://www.gfoss.it/drupal/opendata

come potete vedere [Allegato B], per i grid
viene proprio consigliato l'uso delle (ESRI)
Ascii Grid, dei (Geo)Tiff e dei vari formati
binari supportati da USGS

il documento non dice nulla per i TIN (sorry):
ma vedo che il buon vecchio SHP supporta uno
"strano" MultiPatch, che a naso assomiglia tanto
ad un TIN:
http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf
(pag. 20,21 e successive)

chiedo a chi ne sa sicuramente molto più di me:
il MultiPatch SHP non potrebbe rappresentare un
ragionevole punto di partenza per i TIN ?

-------------------------------

giusto un paio di considerazioni di ordine generale,
cercando di ragionare terra terra:

ad un estremo abbiamo i "formati aperti" veri e 
propri: pubblicamente documenti, magari supportati 
da una specifica ISO (o simile), liberi da qualsiasi 
brevetto e/o copyright, magari anche largamanete 
supportati da API e tools open source (e magari
anche da API e tools proprietari).
Esempi classici: PNG, JPEG, (tappandosi il naso,
mettiamoci anche TIFF), tutta la roba W3C (TCP/IP,
HTTP, HTML, CSS etc), i vari standard OGC

all'estremo opposto abbiamo i "formati chiusi": per
nulla documentati, magari volutamente offuscati, 
coperti da qualche brevetto o soggetti a copyright. 
utilizzabili solo ed esclusivamente tramite API e 
tools di un unico produttore, magari solo su un'unica 
piattaforma (in genere, Win)
Esempi classici: ECW, MrSID, DWG

il mondo non funziona quasi mai in base alla legge
del "tutto o nulla": fortunatamente in genere c'è
sempre un'ampia gamma di sfumature di grigio tra
gli estremi opposti.

quindi abbiamo una lunga serie di formati che si
collocano nel mezzo.
ragionando in termini empirici, fino a quando esiste
uno straccio di documentazione (oppure fino a quando
il formato è tanto stupido da essere auto-intuitivo),
e fino a quando non esistono brevetti e copyright che
pongono restrizioni invalicabili, possiamo comunque
considerarli come "formati 'quasi' aperti".
se poi sono largamente supportati da API e tools
sia open source che proprietari, allora per quanto
mi riguarda possiamo considerarli come "standard
de facto", che favoriscono l'interoperabilità.
Esempio classico: ESRI Shapefile; difficilmente
possiamo definirlo "aperto", ma nei fatti è la
colla universale che tutti sanno utilizzare senza
alcun problema, sia nel mondo del sw libero che
nel mondo del sw proprietario.

Altro esempio: i vari formati TXT e CSV sarebbe
più giusto definirli (s)formati; non esiste uno
straccio di specifica formale.
ma poichè sono demenzialmente semplici da supportare,
finisce che rappresentano lo strumento più universale
che si possa utilizzare.
XML fa le stesse identiche cose, ed in più è
rigorosamente formalizzato da specifiche pubbliche:
resta il fatto che XML è molto più rognoso da
supportare, quindi in moltissimi casi TXT/CSV
rappresenta un'alternativa assai più pratica.

Un ulteriore esempio: GIF è stato per anni una
"bestia nera", visto che era coperto da brevetto.
oggi il brevetto è scaduto; e GIF è a pieno titolo
un formato che possiamo considerare "aperto", visto
che tutti lo sanno creare e/o visualizzare.

Esempio da avvocato del diavolo: 7Zip è completamente
open; ma purtroppo è anche assai meno supportato
rispetto a Zip (anche se è decisamente più potente).
Buon senso dice che è meglio rilasciare i dati 
compressi come Zip, non come 7Zip: perchè in questo
modo si semplifica sicuramente la vita agli utenti.

quindi, tornando a bomba: perchè mai non usare
le (ESRI) Ascii Grids ?
in fondo sono semplicemente un banale TXT giusto
adattato al ruolo: qualsiasi sviluppatore può
leggere/scrivere un ascii grid con pochissimo
sforzo. e non a caso, la quasi totalità dei
tools GIS riesce ad acquisire e ad esportare
un'Ascii Grid

my 2 cents
Sandro