Quale formato?
Locked
12
12
 
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1 Salve. Siamo credo tutti d'accordo che shp non e' un buon formato, da molti se non tutti i punti di vista. La nascita e la standardizzazione del GeoPackage aveva dato speranze di trovare un efficace sostituto, ma il tempo e' passato, e non pare che molto sia cambiato: http://jamesfee.us/post/101781709416/nearly-2-years-ago-you-were-praising-geopackage-as-a La questione: a questo punto, cosa e' piu' opportuno usare, sia per l'uso normale che per la condivisione? Forse GeoJSON? Pareri? Saluti. - -- Paolo Cavallini - www.faunalia.eu QGIS & PostGIS courses: http://www.faunalia.eu/training.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlRfT3kACgkQ/NedwLUzIr5zFgCeLLo9BudHwZ0jW8+IgI50bnv3 oNMAoKnJVZyE2MOwnqzxEXN3posVmD2J =W+OM -----END PGP SIGNATURE----- _______________________________________________ [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+40 iscritti al 5.6.2014 |
|
|
Visto che si parte dal punto di vista che lo shp non è un buon formato.
Sicuramente un buon modo di procedere potrebbe essere quellodi elencare le sue manchevolezze. Almeno si ha un termine di paragone con altri formati. Eviterei infatti di scegliere un formato che oi alla prova dei fatti si potrebbe dimostrare peggiore di quello che si lascia. Come contributo io fornisco la mia disamina: esri shapefile: .)non prevede l'indicazione del CharacterSet .)e' limitato nella dimensione del record .)limita di 10 caratteri al nome di un campo .)non supporta geometrie complesse (solamente punti linee e poligoni, simple e multi) .)ha un limite di 2GB per la parte alfanumerica (file dbf) .)ha un limite di 2 GB per la parte geometrica .)le geometrie sono in doppia-precisione .)non possiede l'indicazione del NULL nei valori alfanumerici .)non ha standardizzato l'indice spaziale .)la presenza di formati leggermene difformi sul dbf impatta anche sullo shapefile .)la separazione fisica tra shp e dbf fa' si' che un eiditng separato (mediante excel ad esempio) del dbf provoca la perdita del link con la geometria corrispondente dimentico qualcosa ? Saluti, A. Il 09/11/2014 12:26, Paolo Cavallini ha scritto: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Salve. > > Siamo credo tutti d'accordo che shp non e' un buon formato, da molti > se non tutti i punti di vista. La nascita e la standardizzazione del > GeoPackage aveva dato speranze di trovare un efficace sostituto, ma il > tempo e' passato, e non pare che molto sia cambiato: > > http://jamesfee.us/post/101781709416/nearly-2-years-ago-you-were-praising-geopackage-as-a > > La questione: a questo punto, cosa e' piu' opportuno usare, sia per > l'uso normale che per la condivisione? Forse GeoJSON? > Pareri? > > Saluti. > - -- > Paolo Cavallini - www.faunalia.eu > QGIS & PostGIS courses: http://www.faunalia.eu/training.html > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iEYEARECAAYFAlRfT3kACgkQ/NedwLUzIr5zFgCeLLo9BudHwZ0jW8+IgI50bnv3 > oNMAoKnJVZyE2MOwnqzxEXN3posVmD2J > =W+OM > -----END PGP SIGNATURE----- > _______________________________________________ > [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+40 iscritti al 5.6.2014 _______________________________________________ [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+40 iscritti al 5.6.2014 |
|
Tutto giusto, Andrea, tranne l'ultimo punto: la vera potenza del formato Shape sta proprio nella sua modularita' e distinzione fra geometria ed attributi.
Da sempre edito i file DBF nel foglio elettronico, e non ho mai corrotto nulla, proprio perche' basta applicare la regola aurea: e' vietato alterare la sequenza delle righe (scambiandole, aggiungendole o sottraendole), mentre hai carta bianca su contenuto e numero delle colonne... |
|
|
Giusto contradditorio.
Difendo le mie ragioni: resto convinto che sia un difetto. Il tuo e' un workaround che te sfrutti in maniera sapiente, ma e' un wrkaround e non pu' essere visto come un pregio. Il fatto che un utente possa editare il dbf usando sturmenti non GIS puo' provocare la perdita dell'allineamneto e questo e' un rischio che potrebbe compromettere il dato. Quindi e' un difetto. Per spiegarmi meglio: se apri una tabella di postgres ve vi e' un campo geometrico aggiunto da postgis, e lo apri con un client che none' GIS ad esempocon un foglio elettronico che hai precedentemente connesso a tale DB tramite un odbc. (giusto per fare un esmepio) te puoi fare di tutto, ma l'allineamento tra parte attributi e arte geometirc a non lo perdi. Ovviamente se cancelli la colonna geometrica si, ma quella e' una operazione di alterzaione della struttura . Io parlo di operazioni di inserimento/cancellazione/modifica. Pr cui secondo me e' un difetto il fatto che lo shapefile non abbia una corrispondenza rigida tra attributi e geometria. A lei la parola vostro onore... :) Il 09 novembre 2014 14:53, Sieradz <[hidden email]> ha scritto: > Tutto giusto, Andrea, tranne l'ultimo punto: la vera potenza del formato > Shape sta proprio nella sua modularita' e distinzione fra geometria ed > attributi. > > Da sempre edito i file DBF nel foglio elettronico, e non ho mai corrotto > nulla, proprio perche' basta applicare la regola aurea: e' vietato alterare > la sequenza delle righe (scambiandole, aggiungendole o sottraendole), mentre > hai carta bianca su contenuto e numero delle colonne... > > > > -- > View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Quale-formato-tp7590196p7590198.html > Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com. > _______________________________________________ > [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+40 iscritti al 5.6.2014 -- ----------------- 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+40 iscritti al 5.6.2014 |
|
|
In reply to this post by Andrea Peri
On Sun, 09 Nov 2014 13:31:24 +0100, aperi2007 wrote:
> Visto che si parte dal punto di vista che lo shp non è un buon > formato. > > Sicuramente un buon modo di procedere potrebbe essere quellodi > elencare le sue manchevolezze. > Almeno si ha un termine di paragone con altri formati. > > Eviterei infatti di scegliere un formato che oi alla prova dei fatti > si potrebbe dimostrare peggiore di quello che si lascia. > > Come contributo io fornisco la mia disamina: > > esri shapefile: > .)non prevede l'indicazione del CharacterSet > .)e' limitato nella dimensione del record > .)limita di 10 caratteri al nome di un campo > .)non supporta geometrie complesse (solamente punti linee e poligoni, > simple e multi) > .)ha un limite di 2GB per la parte alfanumerica (file dbf) > .)ha un limite di 2 GB per la parte geometrica > .)le geometrie sono in doppia-precisione > questo non necessariamente e' un difetto ;-) magari se supportasse anche la singola precisione in qualche caso consentirebbe di risparmiare circa il 50% di spazio. comunque nel grande ci sta' anche il piccolo: e' un po' sciupone, ma tutto sommato e' un compromesso molto ragionevole > .)non possiede l'indicazione del NULL nei valori alfanumerici > .)non ha standardizzato l'indice spaziale > .)la presenza di formati leggermene difformi sul dbf impatta anche > sullo shapefile > .)la separazione fisica tra shp e dbf fa' si' che un eiditng separato > (mediante excel ad esempio) del dbf provoca la perdita del link con > la > geometria corrispondente > > dimentico qualcosa ? > - il supporto per i campi Date offerto dal DBF e' rudimentale; quello per Time e Timestamp e' addirittura del tutto assente. l'implementazione e' lontana anni luce dalle prescrizioni ISO-8601. decisamente un pessimo formato per rappresentare informazioni che richiedono anche una localizzazione precisa nel tempo oltre che nello spazio. - il DBF non consente di gestire campi BLOB se non tramite gli esoterici MEMO, peraltro non supportati da molte implementazioni. in pratica: se le tue features sono corredate p.es. da qualche foto non e' possibile esportarle via SHP, se non tramite qualche spericolata acrobazia (assolutamente fuori standard). - il meccanismo scelto per rappresentare l'exterior ring e gli eventuali interior rings di un poligono lascia molto a desiderare (e non di rado e' fonte di pasticci). si vede che e' un formato nato al tempo dei dinosauri; tutti i formati nati in seguito (WKT, GML, GeoJSON, KML etc) usano un modello geometrico molto piu' sano. - indovinare lo SRID associato ad uno SHP rasenta la magia nera. ok, il file .prj offre un qualche aiuto: ma troppo spesso non viene fornito, e comunque ricavare uno SRID "certo" a partire dalla definizione di un CRS in formato WKT contenuta nel .prj e' tutt'altro che un'operazione facile e di robusta affidabilita' universale. ------- mi permetto di sottolineare un punto decisamente critico e di interesse assolutamente generale per qualsiasi formato di interscambio. i numeri floating-point possono essere rappresentati sia in forma binaria (IEEE-754) sia in forma testuale. la forma binaria garantisce sempre nel modo piu' rigoroso che il valore verra' trasferito senza nessuna alterazione. invece la forma testuale e' sempre inevitabilmente soggetta a leggere oscillazioni (arrotondamenti/troncamenti) quando viene converita avanti ed indietro dalla corrispondente notazione binaria usata internamente. dipende fortemente dal numero di cifre intere e decimali, dall'architettura della CPU e pure dalle librerie di run-time di basso livello utilizzate; insomma, non e' affatto un processo controllabile in modo robustamente deterministico. giusto per spiegarmi meglio, questo e' esattamente quel che accade quando si converte in formato testuale 100.4999999 a seconda del numero di cifre decimali utilizzate: 100.5000 100.500000 100.49999990 100.499999900000 ma possono accadere effetti ancora piu' bizzarri: questo e' come viene gestito 1234567.987654321 su Windows (MinGW): 1234567.987654320900 invece su Fedora (gcc) accade questo: 1234567.987654320896 non solo abbiamo valori binari diversi sulle due piattaforme, ma in nessun caso abbiamo mai il "valore vero" :-) usare formati text-based e' sicuramente simpatico sotto molti aspetti, ma non sempre e non necessariamente e' sano quando preservare la precisione assoluta dei valori floating point ha un ruolo critico (p.es. quando ci sono stretti vincoli topologici da rispettare). e' sempre bene essere fortemente consapevoli che usare notazioni testuali implica inevitabilmente il rischio di introdurre arrotondamenti e troncamenti indesiderati e fuor di controllo; e quanti piu' passaggi intermedi subiscono i dati tanto piu' il rischio diventa certezza assoluta (con ovvi casini a seguire). torniamo a bomba sullo Shapefile; le coordinate delle geometrie sono rappresentare secondo IEEE-754, e quindi sono a prova di bomba (ottimo): viceversa gli attributi con decimali sono rappresentati nel DBF in forma testuale (ahi ahi ahi). e' un po' come dire che su un piede hai uno stivale e sull'altro una ciabatta ... non e' proprio il massimo del comfort :-D ok, il DBF supporta anche i fp IEEE-754, ma e' un'opzione abbastanza stavagante e non universalmente supportata; puo' cusare grossi problemi di interoperabilita'). insomma, e' l'ulteriore conferma che si tratta di un formato vecchio, progettato un po' alla garibaldina e non sempre rigorosamente consistente in tutti i suoi aspetti. ma proprio per questo ... e' immortale ed insostituibile :-D my 2 cents, 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+40 iscritti al 5.6.2014 |
|
|
sorry, nella precedente mi sono dimenticato di aggiungere
il capo d'accusa principale a sfavore dello Shapefile. il fatto che si tratti di almeno tre files distinti che vanno letti in simultanea rende tutta l'architettura incredibilmente fragile. quante volte e' capitato a ciascuno di noi di ricevere da un collega uno shp inutilizzabile perche' ci si era dimenticati di allegare almeno uno dei membri indispensabili ? e quante volte e' capitato di trovare (anche su presigiosi siti istituzionali, e non solo italiani) shp che non funzionano su Linux perche' su Win era stato fatto qualche gran macello mescolando a casaccio path in tutte maiuscole e path in tutte minuscole ? nessuna delle altre potenziali alternative soffre di un difetto di progettazione cosi' platealmente smaccato. 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+40 iscritti al 5.6.2014 |
Administrator
|
In reply to this post by pcav
una domanda (storica) però mi sorge immediata:
se è, come è vero, un formato orrendo, perchè è ancora in pista da più di 20 anni e gode di ottima salute tra molti utenti? non si può negare infatti che al netto di tutti i difetti che sono stati elencati, in 2 secondi comincio a popolare una struttura fisica che ho impiegato 10 minuti a creare. i sostituti mantengono/manterranno questa semplicità? s. |
|
|
Perche' e' interscambiabile, esattamente come il formato DXF nel mondo Cad, e quello RTF nel 'word processing'. L'unico grave difetto che io vedo e' che, a fronte dell'obbligatorieta' della triade SHP/DBF/SHX, ci si e' ostinati a mantenere opzionale la presenza del file PRJ. Questa mancanza rende indefinita la posizione di una shape sul geoide, analogamente alla 'stupida' coppia TIF/TFW del mondo raster ove occorre "indovinare" il corretto SR. |
|
|
In reply to this post by a.furieri
Vediamo se riesco a rispondenti dallo smartphone. Il 09/nov/2014 15:30 <[hidden email]> ha scritto: >> esri shapefile: Io penso che lo sia nella misura in cui determinati valori sono preclusi. Stiamo parlando di un formato di scambio. > > Su questo confesso che a livello personale sono d'accordo con te. > - il DBF non consente di gestire campi BLOB se non tramite gli Qui hai perfettamente ragione. > in pratica: se le tue features sono corredate p.es. da qualche Questo è già contemplato nella asserzione che non supporta geometrie complesse. Che il modello shp di boundary e gole non sia il massimo siamo d'accordo. Ma per lo scambio può essere sufficiente. Ogni formato nasce con in mente un obiettivo e avrà dei punti deboli. > - indovinare lo SRID associato ad uno SHP rasenta la magia nera. Anche qui hai ragione. Manca l indicazione dello srid. Il file prj non è obbligatorio e questo è un difetto. Avrei potuto aggiungere che è un difetto anche avere un srid a livello di tabella anziché di riga. Ma penso che andrei troppo sul sofisticato. Il mondo non è pronto a ciò. > Ti rispondo in fondo . Aalla fine della tua lunga disamina. > i numeri floating-point possono essere rappresentati sia in forma Non sono d'accordo. Il tuo ragionamento contiene una condizione nascosta. Ovvero che sia il.sistema di partenza che quello di arrivo abbiano la medesima precisione . A. _______________________________________________ [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+40 iscritti al 5.6.2014 |
|
|
In reply to this post by stefano campus
er ora stiamo elencando i difetti dello shapefile.
Noterai che tra i suoi difetti non e' la mancanza di diffusione su piu' piattaforme. Ovviamente quando e se di dovesse andare a esaminare altri formati , e' eviente che non si potrebbe non prescindere dal fatto che sia o meno diffuso. E' altrettanto ovvio che l'essere presente sulla piattaforma gdal/ogr puo' essere un punto a favore, ma puo' non esserlo se alla fine per colloquiare tra due piattaforme molto differenti servisse passare dallo shapefile. Insomma identificare un buon formato di scambio, se non si vuole solo fare una opera di marketing nei confronti di un formato anziche' di un altro, non è facile perche' sono molti i parametri. E non ultimo lo e' il mercato. Te poi prendere il formato piu' intelligente del mondo e piu' efficiente , etc.. Ma se non inciampa nelle giuste fasi lunari e ha pure fortuna non diventera' mai il formato di scambio usato da tutti i principali softwares GIS. :) Il 09 novembre 2014 16:39, stefano campus <[hidden email]> ha scritto: > una domanda (storica) però mi sorge immediata: > se è, come è vero, un formato orrendo, perchè è ancora in pista da più di 20 > anni e gode di ottima salute tra molti utenti? > non si può negare infatti che al netto di tutti i difetti che sono stati > elencati, in 2 secondi comincio a popolare una struttura fisica che ho > impiegato 10 minuti a creare. > > i sostituti mantengono/manterranno questa semplicità? > > s. > > > > -- > View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Quale-formato-tp7590196p7590204.html > Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com. > _______________________________________________ > [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+40 iscritti al 5.6.2014 -- ----------------- 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+40 iscritti al 5.6.2014 |
|
|
In reply to this post by stefano campus
On Sun, 9 Nov 2014 08:39:02 -0700 (MST), stefano campus wrote:
> una domanda (storica) però mi sorge immediata: > se è, come è vero, un formato orrendo, perchè è ancora in pista da > più di 20 > anni e gode di ottima salute tra molti utenti? > esiste un brillante saggio su questo tema scritto da Stephen Jay Gould, paleontologo nonche' geniale esegeta dell'evoluzione darwiniana: e ve lo potete leggere facilmente (in lingua italiana) tramite questa URL: http://books.google.it/books?id=TviNsjVqlNQC&pg=PA63&lpg=PA63&dq=gould+evoluzione+tastiera+qwerty&source=bl&ots=5C-s1tK1og&sig=DhjEF8ZSf8duo4PjUkilO3aGymA&hl=it&sa=X&ei=14xfVOiEI4qM7QbI_YHICw&ved=0CCwQ6AEwAg#v=onepage&q=gould%20evoluzione%20tastiera%20qwerty&f=false (pagine da 60 a 71) riassuntino ultra-short per i piu' frettolosi: ---------------------------------------------- le tastiere QWERTY sono decisamente sub-ottimali, e gia' nel corso del XIX secolo erano stati proposti altri arrangiamenti alternativi sicuramente piu' razionali e piu' efficienti. ma con la tecnologia tutta meccanica tasto-leva-molla-carattere QWERTY aveva il vantaggio di minimizzare statisticamente i blocchi dovuti a due o piu' leve che si accavallavano e si incastravano, e quindi era la soluzione preferita dai fabbricanti. e' del tutto evidente che almeno da mezzo secolo non esistono piu' problemi meccanici di leve che si incastrano, visto che nel frattempo siamo passati a tecnologie prima elettromeccaniche e poi digitali. allora perche' QWERTY continua ad essere egemone ancora oggi ? semplicemente perche' ormai si e' radicato troppo in profondita'; i meriti o demeriti tecnici ormai sono del tutto irrilevanti, trinfano la forza di inerzia e le abitudini ben consolidate. centinaia di milioni di utenti quando hanno iniziato ad usare un computer per la prima volta in vita loro avevano gia' una buona familiarita' con le macchine da scrivere con tastiera QWERTY; ancora oggi negli anni 2000 miliardi di persone che non hanno mai usato materialmente una macchina da scrivere continuano comunque ad aspettarsi una tastiera QWERTY semplicemente perche' e' quella universalmente diffusa e perche' e' esattamente quella che sono abituati ad usare da sempre. la situazione si e' definitivamente cristallizzata: non c'e' piu' nessuno spazio operativo per l'innovazione. 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+40 iscritti al 5.6.2014 |
|
|
Meno male che almeno quella si ' e' cristallizzata.
Ci mancava pure che ogni computer avesse un metodo di immissione dati differente. :) Gia' e' stato un trauma quando nei computer e' scomparsa la porta parallela , seriale e ps/2 per lasciare spazio solo a porte USB. Ho dovuto ricomprare tastiera, mouse e stampante. A. Il 09 novembre 2014 18:34, <[hidden email]> ha scritto: > On Sun, 9 Nov 2014 08:39:02 -0700 (MST), stefano campus wrote: >> >> una domanda (storica) però mi sorge immediata: >> se è, come è vero, un formato orrendo, perchè è ancora in pista da più di >> 20 >> anni e gode di ottima salute tra molti utenti? >> > > esiste un brillante saggio su questo tema scritto da Stephen Jay Gould, > paleontologo nonche' geniale esegeta dell'evoluzione darwiniana: e ve > lo potete leggere facilmente (in lingua italiana) tramite questa URL: > > http://books.google.it/books?id=TviNsjVqlNQC&pg=PA63&lpg=PA63&dq=gould+evoluzione+tastiera+qwerty&source=bl&ots=5C-s1tK1og&sig=DhjEF8ZSf8duo4PjUkilO3aGymA&hl=it&sa=X&ei=14xfVOiEI4qM7QbI_YHICw&ved=0CCwQ6AEwAg#v=onepage&q=gould%20evoluzione%20tastiera%20qwerty&f=false > > (pagine da 60 a 71) > > riassuntino ultra-short per i piu' frettolosi: > ---------------------------------------------- > le tastiere QWERTY sono decisamente sub-ottimali, e gia' nel corso > del XIX secolo erano stati proposti altri arrangiamenti alternativi > sicuramente piu' razionali e piu' efficienti. > ma con la tecnologia tutta meccanica tasto-leva-molla-carattere QWERTY > aveva il vantaggio di minimizzare statisticamente i blocchi dovuti a > due o piu' leve che si accavallavano e si incastravano, e quindi era > la soluzione preferita dai fabbricanti. > e' del tutto evidente che almeno da mezzo secolo non esistono piu' > problemi meccanici di leve che si incastrano, visto che nel frattempo > siamo passati a tecnologie prima elettromeccaniche e poi digitali. > > allora perche' QWERTY continua ad essere egemone ancora oggi ? > semplicemente perche' ormai si e' radicato troppo in profondita'; > i meriti o demeriti tecnici ormai sono del tutto irrilevanti, > trinfano la forza di inerzia e le abitudini ben consolidate. > > centinaia di milioni di utenti quando hanno iniziato ad usare un > computer per la prima volta in vita loro avevano gia' una buona > familiarita' con le macchine da scrivere con tastiera QWERTY; > ancora oggi negli anni 2000 miliardi di persone che non hanno mai > usato materialmente una macchina da scrivere continuano comunque > ad aspettarsi una tastiera QWERTY semplicemente perche' e' quella > universalmente diffusa e perche' e' esattamente quella che sono > abituati ad usare da sempre. > > la situazione si e' definitivamente cristallizzata: non c'e' piu' > nessuno spazio operativo per l'innovazione. > > 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+40 iscritti al 5.6.2014 -- ----------------- 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+40 iscritti al 5.6.2014 |
|
|
In reply to this post by pcav
> La questione: a questo punto, cosa e' piu' opportuno usare, sia per
> l'uso normale che per la condivisione? Forse GeoJSON? shp file è pessimo per le ragioni che ha già esposto Andrea geopackage sembra vincente ma non decolla (discorso analogo per il gml) geojson si sta imponendo ma pure questo ha i suoi limiti (es. la metadatazione degli attributi) kml sarebbe valido, se però fosse distribuito secondo le reali specifiche del ogc (che prevede la dichiarazione dei metadati degli attributi) invece che usare solo quelle per pilotare i prodotti google e restringere le informazioni degli attributi in un solo campo formattato in html (odioso e a basso riuso) In sintesi: preferisco usare formati diversi in relazione ad utenti diversi, magari con dei link ad un wfs che in realtà converte on the fly _______________________________________________ [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+40 iscritti al 5.6.2014 |
|
|
In reply to this post by stefano campus
Il futuro è dei Database su file.
Un DBMS (noi puntiamo su Splite e personalmente sono diffidente rispetto ad un geopackage voluto dalle multinazionali) consente di conservare tutto quanto occorre, mantenendo relazioni, indici, (in prospettiva) metainformazione e vestizioni, (in prospettiva) history delle operazioni fatte per costruire la tabella, la capacità di produrre facilmente statistiche sui domini delle diverse colonne, ecc. Stiamo verificando la possibilità di sfruttarlo anche per i dati raster. Stiamo investendo sul porting da GVSIG+Postgres verso Qgis+Splite di modellli numerici per interagire con dati materia di acque sotterranee e superficiali (Sid&Grid). Splite è fenomenale anche per la pubblicazione di dati (molti nostri WMS attingono a tabelle su Splite, e magari dallo stesso DBMS attinge anche un Dataseltzer per servire i medesimi dati sotto forma di viste interrogabili). Uno shp non consente nulla di tutto questo. Ed è delicatissimo (dal rischio di sfasare DBF rispetto a SHP, al fatto che non veicola notizia rispetto allo SRID). Il fatto è che nessuno si pone il problema di "progettarsi" il proprio formato dati, ma tutti aspettano quello che gli arriverà dalle multinazionali! Credo ed auspico che il futuro possa vedere la massima diffusione dei DBMS: repository robusti (Postgresql+Postgis) affiancati da DBMS su file (agili da scambiare), con capacità di eseguire (sia su PG che su SPLITE) query geografiche funzionali sia alla verifica/collaudo/predisposizione dei dati che alla loro pubblicazione/divulgazione. Dei client GIS e WebGIS (tramite servizi WMS/WFS) che accedono ai dati conservati in quei DBMS (sarebbe fantastico avere lo stesso GRASS ed R accedere in maniera nativa ai dati sui DBMS). E tools GDAL/OGR per trasferire dati da un formato/vettore ad un altro (facendosi carico, ove disponibili, anche di metainformazione e vestizioni). Il 09/11/14, stefano campus<[hidden email]> ha scritto: > una domanda (storica) però mi sorge immediata: > se è, come è vero, un formato orrendo, perchè è ancora in pista da più di 20 > anni e gode di ottima salute tra molti utenti? > non si può negare infatti che al netto di tutti i difetti che sono stati > elencati, in 2 secondi comincio a popolare una struttura fisica che ho > impiegato 10 minuti a creare. > > i sostituti mantengono/manterranno questa semplicità? > > s. > > > > -- > View this message in context: > http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Quale-formato-tp7590196p7590204.html > Sent from the Gfoss -- Geographic Free and Open Source Software - Italian > mailing list mailing list archive at Nabble.com. > _______________________________________________ > [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+40 iscritti al 5.6.2014 [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+40 iscritti al 5.6.2014 |
|
|
In reply to this post by Andrea Peri
Finalmente mi consolo ...pensavo di essere stato l'unico a soffrire per quella triste dipartita dell'hardware ;-) P.S. ...soprattutto per il mio amato software di geotecnica, che aveva il codice criptato della licenza d'uso inglobato nella "spina" seriale ...niente più porta seriale nel PC, niente più possibilità di poter usare quel software. |
|
|
[OT] Premesso che le chiavi hardware viaggiavano su porta parallela (e non seriale), puoi sempre comprarti una scheda LPT da montare nello slot PCI o PCI-E: costa cara, ma almeno sfrutti la licenza... [/OT] :) |
|
|
In reply to this post by Maurizio Trevisani
Concordo in pieno! Lo shapefile ormai dovrebbe essere messo al bando per tutti i motivi che Andrea ha ben elencato.
Anche per me i GeoDB al momento rimangono la migliore alternativa perché sono quelli che offrono maggiori potenzialità. Tra tutti Splite mi pare l'unico papabile su filesystem (ma magari mi sto perdendo qualche altro formato che non conosco). Di GeoPackage (che mi pare si basi fortemente su Splite) non ho ben capito cosa lo stia tenendo fermo al palo. Capisco il punto di vista di Stefano che fa notare come un geoDB non sia un formato immediato come lo shapefile. Salvare una semplice selezione o il risultato di un elaborazione dentro un file Splite senza passare da SQL non è un operazione immediata da fare come per lo shapefile. Anche alcuni limiti di Sqlite, come ad esempio l'impossibilità di cancellare colonne per citarne uno, possono essere un freno. Il rapporto pro/contro però mi pare ancora molto maggiore di uno! Probabilmente una buona integrazione tra Splite, GDAL/OGR e client GIS potrebbe aiutare a superare anche questi ultimi ostacoli. ^L^ Il giorno 09 novembre 2014 23:40, Maurizio Trevisani <[hidden email]> ha scritto: Il futuro è dei Database su file.
Stiamo verificando la possibilità di sfruttarlo anche per i dati raster. _______________________________________________ [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+40 iscritti al 5.6.2014 |
|
|
In reply to this post by pcav
Il giorno 09 novembre 2014 12:26, Paolo Cavallini <[hidden email]> ha scritto: -----BEGIN PGP SIGNED MESSAGE----- Pareri? Di GeoJSON il primo limite forte che vedo è che (almeno mi pare) non supporta indici spaziali, quindi poco adatto per dati "corposi". Il vantaggio rispetto a SL è invece che quando si hanno pochi dati i file rimangono contenuti, mentre SL, portandosi dietro tutta la struttura di un DBMS, crea un file di 4 Mb anche per un solo punto. Conosco poco il mondo di CouchDB, mi pare che OGR lo supporti, ma di più non so. ^L^ Saluti. _______________________________________________ [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+40 iscritti al 5.6.2014 |
|
|
In reply to this post by Sieradz
[OT] OOps ...hai ragione ...parallela. [OT] Sto seguendo questa bellissima e stimolante discussione su i pro e i contro dei vari formati e volevo inserirmi, in punta di piedi e a bassa voce, solo per rappresentare anche l'aspetto "affettivo" della questione. Per chi come me si è abituato alla semplicità e all'intuitività dello shapefile (anch'io, ad esempio, trovo molto comodo poter integrare o modificare il file dbf con un foglio elettronico, rispettando però sempre la bidirezionalità con il file shp) sarà doloroso (anche se inevitabile) abbandonare il mitico "uno e trino" shapefile per altri formati sicuramente più performanti. Tutto qui. |
|
|
In reply to this post by Luca Lanteri-3
Grazie Luca del contributo alla discussione/disamina dei vari formati.
Permettimi di controdedurre le tue osservzioni: SU GeoJSON . Riconosco che la mancanza di un indice spaziale sia un difetto. Secondo lacuni punti di vista questo non è un limite per un formato destinato all'interscambio dei dati tra vari programmi. Per me lo e' perche' in effetti uno potrebbe volersi estrarre una selezione dei dati per il caricamento e il disporre di un indice spaziale velocizzerebbe tale operazione. Diciamo che non ' una delle mancanze piu' serie, ma se ce non dispiace. Va anche chiarito che nel caso dello shapefile , l'indice spaziale esisterebbe. Pero' non e' standardizzato e questo ne limita parecchio l'impiego riducendolo solo ai casi in cui si scambia i dati tra softwares del medesimo tipo . Altrimenti si opera senza indice spaziale. Per quanto riguarda lo spatialite. Anche li' ci sono degli indubbi difetti. Sinceramente non avrei considerato l'overhead tra i difetti, ma visto che lo segnali ce lo aggiungo. Poi ne aggiungo altri che a parer mio lo sono. Poi vediamo se anche li' riusciamo a fare una disamina che evidenzi i limit di tale formato . L'impossibilit'a di rinominare o cancellare colonne e' un peso indigeribile in certe situazioni di lavoro, ma non è certo un problema nell'interscambio dei dati. Per cui a parer mio non e' un limite e quindi conteggio la mia opinione come nodif. Anche l'impossibilita' di salvare facilemnte una selezione su uno spatialite non la vedo come un limite dispatialite. Caso mai il limite e' che non vi e' un software che lo supporta a modino. :) di seguito la lista con aggiunto i due formati spatialite e geojson. Ovviamente la lista per questi due non e' completa. Da arricchire con le opinioni di molti. ----------------------------------------------- dif = "e' difetto per" nodif = "non è difetto per" ------------------------------------- Lista difetti del formato ESRI Shapefile .)non prevede l'indicazione del CharacterSet dif: 1 nodif: 0 .)e' limitato nella dimensione del record dif: 1 nodif: 0 .)limita di 10 caratteri al nome di un campo dif: 1 nodif: 0 .)non supporta geometrie complesse (solamente punti linee e poligoni, simple e multi) dif: 1 nodif: 0 .)ha un limite di 2GB per la parte alfanumerica (file dbf) dif: 1 nodif: 0 .)ha un limite di 2 GB per la parte geometrica dif: 1 nodif: 0 .)le geometrie sono in doppia-precisione (nel senso di una definizione del numeor di tipo binario ad aritmetica finita) dif: 1 nodif: 1 .)non possiede l'indicazione del NULL nei valori alfanumerici dif:1 nodif: 0 .)non ha standardizzato l'indice spaziale dif: 1 nodif: 0 .)la presenza di formati leggermene difformi sul dbf impatta anche sullo shapefile dif: 1 nodif: 0 .)la separazione fisica tra shp e dbf fa' si' che un editing separato (mediante excel ad esempio) del dbf provoca la perdita del link con la geometria corrispondente dif: 1 nodif: 1 .) mancanza di un vero formato data e time dif: 1 nodif: 1 .) manca un formato blob interno (solo esterno tramite un file acessorio) dif: 2 nodif: 0 .) la geometria non ha lo srid definito (solo un file prj esterno ma opzionale e non standardizzato) dif: 2 nodif: 0 .) la geometria non definisce in maniera chiara e inequivocabile l'exterior ring e gli holes dif: 1 nodif: 1 .) composto di 3 files distinti e indipendenti dif: 1 nodif: 1 .) il campo testo e' limitato a 255 caratteri dif: 1 nodif: 0 ===== Lista difetti del GeoJSON .) non supporta indici spaziali (poco efficiente per grandi moli di dati) dif: 2 ===== Lista difetti dello SpatiaLite .) overhead dimensionale non trascurabile (4mb) che limita il suo impiego quando i dati sono pochi. dif: 1 nodif: 1 .) non consente la rinomina o la cancellazione di una colonna dif: 1 nodif: 1 .) gli attuali software gis che lo supportano in scrittura (qgis only) non permettono un agevole salvataggio su di esso. dif: 1 nodif: 1 FINE (per ora). Il 10 novembre 2014 22:39, Luca Lanteri <[hidden email]> ha scritto: > > Il giorno 09 novembre 2014 12:26, Paolo Cavallini <[hidden email]> ha > scritto: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Salve. >> >> Siamo credo tutti d'accordo che shp non e' un buon formato, da molti >> se non tutti i punti di vista. La nascita e la standardizzazione del >> GeoPackage aveva dato speranze di trovare un efficace sostituto, ma il >> tempo e' passato, e non pare che molto sia cambiato: >> >> >> http://jamesfee.us/post/101781709416/nearly-2-years-ago-you-were-praising-geopackage-as-a >> >> La questione: a questo punto, cosa e' piu' opportuno usare, sia per >> l'uso normale che per la condivisione? Forse GeoJSON? >> >> Pareri? >> > > Di GeoJSON il primo limite forte che vedo è che (almeno mi pare) non > supporta indici spaziali, quindi poco adatto per dati "corposi". > Il vantaggio rispetto a SL è invece che quando si hanno pochi dati i file > rimangono contenuti, mentre SL, portandosi dietro tutta la struttura di un > DBMS, crea un file di 4 Mb anche per un solo punto. > > Conosco poco il mondo di CouchDB, mi pare che OGR lo supporti, ma di più non > so. > > ^L^ > >> Saluti. >> - -- >> Paolo Cavallini - www.faunalia.eu >> QGIS & PostGIS courses: http://www.faunalia.eu/training.html >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1 >> >> iEYEARECAAYFAlRfT3kACgkQ/NedwLUzIr5zFgCeLLo9BudHwZ0jW8+IgI50bnv3 >> oNMAoKnJVZyE2MOwnqzxEXN3posVmD2J >> =W+OM >> -----END PGP SIGNATURE----- >> _______________________________________________ >> [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+40 iscritti al 5.6.2014 > > > > _______________________________________________ > [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+40 iscritti al 5.6.2014 -- ----------------- 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+40 iscritti al 5.6.2014 |
«
Return to Gfoss -- Geographic Free and Open Source Software - Italian mailing list
|
1 view|%1 views
| Free forum by Nabble | Edit this page |