Abbiamo pubblicato alcune pagine descrittive delle strategie che
stiamo cercando di portare avanti. http://www.regione.toscana.it/-/open Ve le segnalo per possibili suggerimenti. Grazie, Maurizio _______________________________________________ [hidden email] 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 |
Il 03/12/2013 12:28, Maurizio Trevisani ha scritto:
> Abbiamo pubblicato alcune pagine descrittive delle strategie che > stiamo cercando di portare avanti. > > http://www.regione.toscana.it/-/open > > Ve le segnalo per possibili suggerimenti. Molto interessante. In particolare la parte con i tutorial in merito agli strumenti GFLOSS. Alcuni suggerimenti: - sulla parte degli open formats aggiungerei qualcosa in merito a qualche piccola attenzione come l'obbligo di fornire il .prj per il formato .shp o la versione per il formato dxf. - sul discorso dati mi spiace che, per alcuni casi, non si sia scelto una licenza compatibile con la ODbL, quindi con OpenStreetMap visto che il dialogo con questa comunità può portare parecchio valore aggiunto. Licenze compatibili, con ugual significato nello share a like, sono la IODL 1.0 e la ODbL. Devo informarmi se la CC-BY-SA versione 4.0 ha superato questi limiti. In ogni caso i miei complimenti perchè, oltre che a fornire dati e software, si fornisce anche un percorso per capire il mondo delle comunità aperte. _______________________________________________ [hidden email] 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 |
On Tue, 03 Dec 2013 15:14:52 +0100, Maurizio Napolitano wrote:
> - sulla parte degli open formats aggiungerei qualcosa in merito a > qualche piccola attenzione come l'obbligo di fornire il .prj per il > formato .shp o la versione per il formato dxf. > sempre per la serie "attenzione ai micro-dettagli": sarebbere estremamente utile indicare sempre esplicitamente il charset-encoding (UTF-8, CP1252, CP850 ...) utilizzato per produrre i vari datasets in formati che non prevedono nessuno standard in merito e che non supportano nessuna forma di auto-documentazione. vedi p.es. .DBF (.SHP) oppure .TXT, .CSV etc etc di norma quasi nessuno (neppure all'estero) si degna mai di indicare chiaramente questa informazione. eppure e' assolutamente critica, visto che un'impostazione errata puo' anche arrivare a rendere del tutto impossibile l'importazione di quei dataset p.es. all'interno di un DBMS, o puo' comunque causare una ricca fioritura di "caratteri pazzi" in corrispondenza di qualsiasi vocale accentata o di qualunque altro segno diacritico particolare non coperto dal charset ASCII nudo e crudo. ciao Sandro _______________________________________________ [hidden email] 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 |
Qui si entra in un mondo ai piu' insospettato e pieno di sorprese. FAccio una domanda:. L'unica soluzione pratica a volte è tentare , se si riesce a stabilire , parlando con chi ha realizzato il dataset, con che sistema operativo e con quale software ha lavorato (se si ha fortuna). Allora si deve ricorrere a una sorta di indagine indiretta. Chiedendo in quale sistema operativo si è operato e con quale software. A volte, con un po' di fortuna ci si riesce a risalire. Questa cosa non è cosi' semplice quando l'interlocutore è una ditta. Le quali spesso affidano a terze parti il lavoro commissionatogli e il nostro stesso interlocutore non ha idea lui medesimo chi realmente ha realizzato lo shapefile, con cosa ha lavorato.
Poi, nei casi peggiori capita pure che la ditta seziona il lavoro a piu' soggetti , ognuno operante con prodotti propri e differenti, e poi rimette tutto insieme senza roppo badare a cosa sta facendo. Idem con i lavori svolti in enti che tipicamente lavorano su gruppi , come ad esmepio universita' o altre strutture del mondo accademico. Dove ovviamente i lavori sono organizzati a gruppi, ma all'intenro dei quali spesso ogni singolo operatore (studente) lavora come crede meglio e come sa' fare. E quindi ci sara' chi usa mac, chi linux e chi windows. Per cui non è assolutamente infrequente che quello che arriva siano dei mix di vari character-sets. A volte ci è capitato di ricevere dati in forma testuale, dove, nel medesimo file di testo , alcune parti erano dotate di CRLF, altre di CR e infine alcune solo di LF !! E ce ne volle del bello e del brutto per spiegare alla ditta di turno che questo era un errore. E poi ci sono i lavori in cui il dataset passa attraverso varie mani in cascata. Ognuna approta delle modifiche. Anche qui, se cambia il computer, e si cambia radicalmente la macchina il character-set cambia. E qui le cose diventano veramente difficili, perche' se si passa da una macchina con CS X1 a una macchina con CS X2, non è vero che si passa a CS X2, dipende cosa si è effettuato. Se si è editato 3 record, ci sta' che solo quei 3 records abbiano cambiato Character-set, mentre gli latri restino con vecchio X1. Invece se si è rigenerato tutto lo shapefile perche' si è fatto , ad esempio, un buffer allora tutto lo shapefile èè passato a X2. Per cui è anche difficile credere che in uno shapefile tutti i records abbiano il medesimo Character-set. Vedi che è un bel casino. Andrea. Il giorno 03 dicembre 2013 16:23, <[hidden email]> ha scritto:
-- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [hidden email] 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 |
On Tue, 3 Dec 2013 17:07:27 +0100, Andrea Peri wrote:
> Qui si entra in un mondo ai piu' insospettato e pieno di sorprese. > > FAccio una domanda: > come si fa' a dedurre il charaxcter-set usato per produrre uno > shapefile ? > che io sappia, esiste un unico modo "galileiano"; provando e riprovando pazientemente, finche' non ci si azzecca ... dopotutto i charset sono "solamente" svariate centinaia :-) anche la mitica scimmia di Darwin a forza di pestare a casaccio sulla tastiera ci puo' riuscire (assumendo un tempo illimitato). > Ovvero. Se arriva uno shapefile , esiste un modo per capire il suo > character-set ? > Non credo. > non risulta neppure a me: proprio per questo sarebbe decisamente importante che questa informazione facesse sempre parte integrante dei metadati, e che venisse indicata con chiara evidenza ogni volta che si decide di pubblicare un dataset come Open Data. > L'unica soluzione pratica a volte è tentare , se si riesce a > stabilire , parlando con chi ha realizzato il dataset, con che > sistema > operativo e con quale software ha lavorato (se si ha fortuna). > Allora si deve ricorrere a una sorta di indagine indiretta. > Chiedendo in quale sistema operativo si è operato e con quale > software. > A volte, con un po' di fortuna ci si riesce a risalire. > esattamente: la metodologia standard e' proprio questa. ma almeno a me personalmente e' capitato piu' volte di perdere lunghe ore (completamente a vuoto, e con irritazione progressivamente crescente) prima di arrivare a capire che quel determinato Shapefile "X" era stato prodotto su un vecchio Mac o magari addirittura in MS-DOS, e che magari non era neppure stato prodotto in Italia ma in qualche paese piu' esotico. sicuramente la fortuna aiuta; ma spesso occorre molta tenacia, una buona dose di know-how, un pizzico di fantasia e soprattutto molto tempo a disposizione. tutte cose che in un mondo di facile interoperabilita' universale e di open data non dovrebbero mai essere strettamente indispensabili :-) > Idem con i lavori svolti in enti che tipicamente lavorano su gruppi , > come ad esmepio universita' o altre strutture del mondo accademico. > Dove ovviamente i lavori sono organizzati a gruppi, ma all'intenro > dei quali spesso ogni singolo operatore (studente) lavora come crede > meglio e come sa' fare. E quindi ci sara' chi usa mac, chi linux e > chi > windows. > Per cui non è assolutamente infrequente che quello che arriva siano > dei mix di vari character-sets. > > A volte ci è capitato di ricevere dati in forma testuale, dove, nel > medesimo file di testo, alcune parti erano dotate di CRLF, altre di > CR e infine alcune solo di LF !! > verissimo, confermo: nel corso degli anni e' capitato anche a me personalmente di trovare qualche dataset "ibrido" che era una sorta di improbabile "collage/mosaico" tra codifiche incompatibili. (e purtroppo anche in tutti i casi che ho avuto la sventura di incontrare personalmente erano sempre prodotti di origine piu' o meno accademica). in genere quando si ha l'incredibile sfortuna di incontrare un mostriciattolo di questa natura le opzioni disponibili sono: A) frullare tutto direttamente nel secchio della spazzatura senza troppi rimpianti B) perdere intere giornate cercando di rattoppare pazientemente tutte le bischerate presenti all'origine C) far finta di nulla, lasciare tutto cosi' com'e' e sperare che nessuno ci faccia mai caso. chiaramente l'unico approccio razionale e' quello "A" :-D forse in casi limite come questi sarebbe magari preferibile *non* pubblicare affatto quei datasets, visto che hanno una qualita' tecnica cosi' indecentemente infima da renderli praticamente inutilizzabili per qualsiasi ulteriore riuso o lavoro derivato. ma in tutti gli altri casi (p.es. SHP o CSV estratti con metodologie informatiche rigorose e ben controllate a partire da un DBMS) resto dell'opinione che sarebbe certamente una saggia "best practice" indicare sempre chiaramente quale charset sia stato utilizzato. ciao Sandro _______________________________________________ [hidden email] 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 |
Credo di non aver ben sottolineato un dettaglio. qualsiasi lavoro GIS svolto da un team che al suo interno usa tecnologie non coordinate tra di loro provoca il rimescolamento dei character-set.TI arriva uno shapefile e ti viene chiesto di correggere 2 records. Quindi è nato un mix di CS. mediante il comando "esporta come". Ma non sono affatto sicuro che questo risolverebbe. Ho infatti il dubbio che in realta' questa azione finisca per incasinare "definitivamente" il dbf dello shapefile. E proprio per questo, non credo che chiunque lavora e opera con gli shapefile possa realisticamente affermare di conoscere il Character-set del suo shapefile, a meno che non lo abbia creato ex-novo lui stesso. Andrea. Il giorno 03 dicembre 2013 18:09, <[hidden email]> ha scritto:
-- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [hidden email] 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 |
Free forum by Nabble | Edit this page |