>“adozione del software libero ed open source, dei formati, dei datiscusate l'intervento un po' provocatorio, ma vorrei esempificare che le cose non sono mai cosi' semplici come sembrano a prima vista. Nella ipotesi teorica che questa legge prendesse corpo, quale sarebbe il formato (aperto e libero) che i tecnici trentini dovrebbero adottare per i grid e per i TIN ? Prendiamo ad esempio l'onnipresente "ascii-grid". Potrei sbagliarmi , ma a me risulta che esso in realta' si chiami "arcinfo ascii grid" (vedi gdal) dal nome della casa che lo ha adottato per prima una certa Esri. http://www.gdal.org/frmt_various.html#AAIGrid E , sebbene sia un formato testuale che tutti leggono con un editor di testo, non riesco a trovare da nessuna parte un qualche accenno che sia un formato libero. Non so' se questo e' realmente vero, ma se cosi' fosse. In questo specifico segmento, i grid ( per i tin la cosa e' anche peggio non esistendo a quel che mi risulta un formato universalmente accettato) quale sarebbe il formato che si dovrebbe adottare ? Grazie, -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 527 iscritti al 7.7.2011 |
2011/10/12 Andrea Peri <[hidden email]>:
>>“adozione del software libero ed open source, dei formati, dei dati >>aperti e dei diritti digitali del cittadino” > > scusate l'intervento un po' provocatorio, > ma vorrei esempificare che le cose non sono mai cosi' semplici come sembrano > a prima vista. > Nella ipotesi teorica che questa legge prendesse corpo, > quale sarebbe il formato (aperto e libero) che i tecnici trentini dovrebbero > adottare per i grid e per i TIN ? Buona domanda... > Prendiamo ad esempio l'onnipresente "ascii-grid". > > Potrei sbagliarmi , ma a me risulta che esso in realta' si chiami > "arcinfo ascii grid" (vedi gdal) > dal nome della casa che lo ha adottato per prima una certa Esri. > > http://www.gdal.org/frmt_various.html#AAIGrid > > E , sebbene sia un formato testuale che tutti leggono con un editor di > testo, non riesco a trovare da nessuna parte un qualche accenno che sia un > formato libero. L'alternativa è GRASS ASCII raster format: http://grass.osgeo.org/grass64/manuals/html64_user/r.in.ascii.html che esiste da circa 1984 che è libero. Uguale per il GRASS Vector ascii format http://grass.osgeo.org/grass64/manuals/html64_user/v.in.ascii.html http://grass.osgeo.org/programming7/vectorlib.html#vlibAscii ciao Markus _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 527 iscritti al 7.7.2011 |
In reply to this post by Andrea Peri
On Wed, Oct 12, 2011 at 08:36:40AM +0200, Andrea Peri wrote:
> >“adozione del software libero ed open source, dei formati, dei dati > >aperti e dei diritti digitali del cittadino” > ... > Nella ipotesi teorica che questa legge prendesse corpo, > quale sarebbe il formato (aperto e libero) che i tecnici trentini dovrebbero > adottare per i grid e per i TIN ? I figli non vanno necessariamente adottati, ma si possono pure fare. Non voglio con questo dire che non esistano formati utilizzabili, non ho sufficienti informazioni sulle esigenze che si vogliono soddisfare e lo stato dei formati che citi. Ma voglio mettere in risalto il fatto che troppo spesso si confonde la liberta' con la convenienza. Se si vuole indagare assieme circa l'esigenza specifica di rappresentazione e scambio di dati organizzati in griglie o triangoli questa lista ed il wiki di gfoss.it sembrano posti molto utili. --strk; () Free GIS & Flash consultant/developer /\ http://strk.keybit.net/services.html _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 527 iscritti al 7.7.2011 |
In reply to this post by Andrea Peri
Il 10/12/2011 08:36 AM, Andrea Peri ha scritto:
>>“adozione del software libero ed open source, dei formati, dei dati >>aperti e dei diritti digitali del cittadino” > > scusate l'intervento un po' provocatorio, > ma vorrei esempificare che le cose non sono mai cosi' semplici come > sembrano a prima vista. > Nella ipotesi teorica che questa legge prendesse corpo, > quale sarebbe il formato (aperto e libero) che i tecnici trentini > dovrebbero adottare per i grid e per i TIN ? Leggi il disegno di legge. Se viene adottato un formato proprietario deve esserne data la motivazione. La legge prevede un organo di controllo sulle scelte prese. _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 527 iscritti al 7.7.2011 |
In reply to this post by Markus Neteler
Bene, ottim esmepio.
Parliamo, a titolo di esempio, del formato grass-ascii-grid. il formato grass-ascii-grid e' proprio un buon esempio per esemplificare i problemi a cui si va incontro. se guardi ai formati di gdal, vedi che gdal e' in grado di leggere e scrivere l'arcinfo-ascii-grid. Il che significa che il buon qgis potrebbe in teoria leggere e scrivere un arcinfo-ascii-grid. Invece, se si guarda al formato Grass Ascii Raster. vedo che gdal lo legge , ma non puo' scriverlo. http://www.gdal.org/frmt_various.html#GRASSASCIIGrid Il che significa che se adottassi quello, gli utenti di qgis (per dirne uno qualsiasi) non potrebbero generarlo. E l'unica strada per generarlo ad oggi e usare grass (caspiterina). Ma questo vorrebbe dire che per prima cosa devono dall'ambiente gis che impiegano esportare i loro dati grid in un formato che gass riesce a importare e poi passarli in grass-grid-ascii. Per cui l'assurdo e' che per poter generare un formato aperto e libero devono passare da un formato non libero (l'arcinfo -ascii-grid). E' un bel paradosso. Si deve impiegare un formato non Libero per arrivare a un formato Libero. Approfitto vigliaccamente di essere nell'argomento per porre un paio di domande :) il formato arcinfo-ascii-grid prevede un file esterno da abbinare e che descrive il sistema di riferimento. Il grass-grid fa una cosa analoga o risolve in altro modo ? E se volessi studiarne le caratteristiche: a parte i comandi per grass, e a parte il sorgente di grass stesso. Sono disponibili delle specifiche di formato ? Andrea. Il giorno 12 ottobre 2011 09:16, Markus Neteler <[hidden email]> ha scritto: 2011/10/12 Andrea Peri <[hidden email]>: -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 527 iscritti al 7.7.2011 |
In reply to this post by Maurizio Napolitano-2
Il giorno mer, 12/10/2011 alle 10.11 +0200, Maurizio Napolitano ha
scritto: > Se viene adottato un formato proprietario deve esserne data la > motivazione. Allora siamo punto e a capo. Le motivazioni si trovano sempre, per qualunque cosa, anche per fare le guerre, figuriamoci per usare un formato proprietario. Io personalmente non ho ancora visto scaturire dalle leggi sul software libero (o open source) un risultato concreto immediatamente positivo, e mi mantengo quindi molto scettico (non prevenuto, semmai postvenuto). Saluti. -- Paolo Cavallini: http://www.faunalia.it/pc _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 527 iscritti al 7.7.2011 |
> Allora siamo punto e a capo. Le motivazioni si trovano sempre, per > qualunque cosa, anche per fare le guerre, figuriamoci per usare un > formato proprietario. > Io personalmente non ho ancora visto scaturire dalle leggi sul software > libero (o open source) un risultato concreto immediatamente positivo, e > mi mantengo quindi molto scettico (non prevenuto, semmai postvenuto). Leggi il documento perche' il comitato di valutazione prevede una presenza forte di esponenti delle associazioni che rappresentano il software libero. Inoltre c'e' un forte impegno sul rilascio di dati aperti utilizzabili a qualsiasi scopo e privi di restrizioni tecnologiche. _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 527 iscritti al 7.7.2011 |
IMHO un formato di file può essere aperto anche se l'ha inventato una
specifica ditta. Basta che le specifiche siano pubbliche e non esistano royalties o brevetti per una sua eventuale implementazione in un software terzo. Nel caso particolare di Esri ascii grid non mi sembra che siano vincoli particolari (ma protrei sbagliarmi) e quindi lo ritengo libero tanto quanto il formato di GRASS. Anzi, verificato che non ci siano vincoli o balzelli collegati, il formato ESRI sarebbe preferibile in quanto supportato da praticamente tutti i software GIS. My 2 cents, Stefano _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 527 iscritti al 7.7.2011 |
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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 527 iscritti al 7.7.2011 |
In reply to this post by Andrea Peri
2011/10/12 Andrea Peri <[hidden email]>:
> Bene, ottim esmepio. > Parliamo, a titolo di esempio, del formato grass-ascii-grid. > > il formato grass-ascii-grid e' proprio un buon esempio per esemplificare i > problemi a cui si va incontro. > > se guardi ai formati di gdal, vedi che gdal e' in grado di leggere e > scrivere l'arcinfo-ascii-grid. > Il che significa che il buon qgis potrebbe in teoria leggere e scrivere un > arcinfo-ascii-grid. > > Invece, se si guarda al formato > Grass Ascii Raster. > > vedo che gdal lo legge , ma non puo' scriverlo. > http://www.gdal.org/frmt_various.html#GRASSASCIIGrid > > Il che significa che se adottassi quello, gli utenti di qgis (per dirne uno > qualsiasi) non potrebbero generarlo. Credo che aggiungere in GDAL il supporto per anche scrivere il formato grass-ascii-grid è piuttosto banale. ciao Markus _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 527 iscritti al 7.7.2011 |
Credimi sulla parola.
In GDAL niente e' banale ! Il giorno 12 ottobre 2011 14:00, Markus Neteler <[hidden email]> ha scritto: 2011/10/12 Andrea Peri <[hidden email]>: -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 527 iscritti al 7.7.2011 |
In reply to this post by Stefano Salvador
Gli obiettivi che le norme propongono per l'adozione dei formati aperti
sono essenzialmente due: _ le pubbliche amministrazioni che producono dati devono garantirsi la costante e futura capacità di usare i propri dati: non devono mettersi nelle condizioni per cui la capacità di utilizzo dei propri dati dipenda dall'utilizzo di SW proprietari, tali per cui se il proprietario del SW decidesse di non consentirne più l'utilizzo alla PA (o la strozzasse con i costi di licenza), questa non sarebbe più in grado di usare i propri dati (mi sembra che qualcosa del genere sia successo tra microsoft e alcuni stati dell'America Latina); _ le pubbliche amministrazioni devono rendere disponibili i propri dati senza obbligare il cittadino ad acquisire licenze onerose per poter leggere quei dati. Da questo punto di vista, un Esri ASCII Grid, letto e scritto da diversi SW, di cui molti anche senza costi di licenza (si mette in evidenza il fatto di SW OpenSource per le PA, per essere in grado di riusare sempre i propri dati, e di SW Freeware per il cittadino, per non obbligarlo a costi per poter leggere il dato), si può assolutamente considerare formato aperto. Condivido quindi quanto afferma Stefano. Chiaramente nella scelta dei formati (aperti) anche altre considerazioni giocano un ruolo: performance, diffusione, compattezza, ecc. Se lo shape file o l'Esri Ascii Grid sono ormai uno standard di fatto, spazi di evoluzione significativi si possono intravedere per: _ geodatabase (dati organizzati, relazionati, comprensivi di tabelle e vocabolari, ecc. in un unico archivio, magari accompagnati da tabelle contenenti la relativa metainformazione, classificazioni, vestizioni, ecc.): es. Spatialite; _ files raster (immagini, DEM, GRID...), magari corredati di piramidi, metainfo, ecc.: es. Rasterlite. Ciao, Maurizio On 12/10/2011 10.35, Stefano Salvador wrote: > IMHO un formato di file può essere aperto anche se l'ha inventato una > specifica ditta. Basta che le specifiche siano pubbliche e non > esistano royalties o brevetti per una sua eventuale implementazione in > un software terzo. Nel caso particolare di Esri ascii grid non mi > sembra che siano vincoli particolari (ma protrei sbagliarmi) e quindi > lo ritengo libero tanto quanto il formato di GRASS. Anzi, verificato > che non ci siano vincoli o balzelli collegati, il formato ESRI sarebbe > preferibile in quanto supportato da praticamente tutti i software GIS. > > My 2 cents, > > Stefano > _______________________________________________ > Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione > [hidden email] > http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss > Questa e' una lista di discussione pubblica aperta a tutti. > Non inviate messaggi commerciali. > I messaggi di questa lista non rispecchiano necessariamente > le posizioni dell'Associazione GFOSS.it. > 527 iscritti al 7.7.2011 Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 527 iscritti al 7.7.2011 |
Free forum by Nabble | Edit this page |