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
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.
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
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 ?
Ovvero. Se arriva uno shapefile , esiste un modo per capire il suo character-set ?
Non credo.
A volte capita che l’interlocutore non ha idea di cosa si sta’ parlando e finisce per chiedere a noi di dirgli quale è il character-set dei dati da lui prodotti.
.
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, <a.furieri@lqt.it> ha scritto:
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 etcdi 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
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
–
Andrea Peri
. . . . . . . . .
qwerty àèìòù
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" 
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
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.
Pensa al caso di uso che ti dicevo.
TI arriva uno shapefile e ti viene chiesto di correggere 2 records.
Per farlo, apri lo shapefile con qgis, correggi e salvi lo shapefile.
Te hai corretto solo due record.
Quei de records avranno il Character-set del tuo PC.
Ma lo shapefile era stato creato in un altro computer, dotato di un altro character-set.
Quindi è nato un mix di CS.
Certamente la colpa è del formato shapefile, che poiche’ non possiede al suo interno una definizione di CS, è soggetto alle idiosincrasie del software e del pc su cui viene editato in un certo momento.
Questa cosa basterebbe da sola a sconsigliare l’impiego dello shapefile per scambiarsi i dati.
Ma visto che lo shapefile è il formato universale per lo scambio dei dati GIS, come ovviare a questo problema ?
L’unic work-around che mi viene in mente , è darsi la regola che anche se si è editato un solo records, sempre rigenerare interamente lo shapefile,
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, <a.furieri@lqt.it> ha scritto:
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 indispensabiliIdem 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”
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