Quale formato?

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Quale formato?

pcav
-----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
Reply | Threaded
Open this post in threaded view
|

Re: Quale formato?

Andrea Peri
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
Reply | Threaded
Open this post in threaded view
|

Re: Quale formato?

Sieradz
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...
Reply | Threaded
Open this post in threaded view
|

Re: Quale formato?

Andrea Peri
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
Reply | Threaded
Open this post in threaded view
|

Re: Quale formato?

a.furieri
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
Reply | Threaded
Open this post in threaded view
|

Re: Quale formato?

a.furieri
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
Reply | Threaded
Open this post in threaded view
|

Re: Quale formato?

stefano campus
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.
Reply | Threaded
Open this post in threaded view
|

Re: Quale formato?

Sieradz
stefano campus wrote
perchè è ancora in pista da più di 20 anni e gode di ottima salute tra molti utenti?

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.
Reply | Threaded
Open this post in threaded view
|

Re: Quale formato?

Andrea Peri
In reply to this post by a.furieri

Vediamo se riesco a rispondenti dallo smartphone.
Tra i punti.

Il 09/nov/2014 15:30 <[hidden email]> ha scritto:
>
> 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.
>>

>> 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
>
>

Io penso che lo sia nella misura in cui determinati valori sono preclusi. Stiamo parlando di un formato di scambio.
E la caratteristica primaria di un formato di scambio è che non alteri i valori nel transito tea due sistemi che non necessariamente hanno il medesimo tipo di dato.

>

>
> - 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.

Su questo confesso che a livello personale sono d'accordo con te.
Ma oggettivamente non è un difetto dal momento che il dato può essere espresso in forma testuale.
Ribadosco che il punto è esaminarlo come formato di scambio.
Una informazione di data e tempo può essere veicolata esattamente in forma testuale.
Il problema è quando il testo contiene caratteri che non si conoscono.

> - il DBF non consente di gestire campi BLOB se non tramite gli
>   esoterici MEMO, peraltro non supportati da molte implementazioni.

Qui hai perfettamente ragione.
Manca un formato blob binario per veicolare informazioni che non sono testuali.
Oppure in alternativa un campo testo con capacita oltre i 255 caratteri dove veicolare il blob in forma codificata oltre che per supportare informazioni testuali oltre i 255caratteri.

>   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.

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.
Per ora resterei a esaminare i difetti dello shapefile.
Non influenzare la corte dichiarando subito le tue preferenze.
:)

> - 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ò.
:)

>
>
> -------
>
> mi permetto di sottolineare un punto decisamente critico e di
> interesse assolutamente generale per qualsiasi formato di
> interscambio.
>

Ti rispondo in fondo . Aalla fine della tua lunga disamina.
:)

> 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
>

Non sono d'accordo.
:)
Le tue obiezioni nei confronti dei formati testuali come già ho accennato prima partono da un presupposto errato.
Un formato di scambio deve avere una risoluzipne e infinita per non introdurre lui una incertezza nel valore.

Il tuo ragionamento contiene una condizione nascosta. Ovvero che sia il.sistema di partenza che quello di arrivo abbiano la medesima precisione .
Onde per cui se si adotta la medesima rappresentazione nulla cambia.
Questo non è vero in senso assoluto.
In testo io scrivo un numero ed è esattamente quello.
In binario io alcuni numeri sono costretto ad approssimarsi . a meno di adottare una rappresentazione ad alta ridondanza come la BCD.
Il fatto che poi una rappresentazione infinita viene approssimata quando si riporta a una finita ancorché binaria è un difetto del sistema di arrivo.

A.
> 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


_______________________________________________
[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
Reply | Threaded
Open this post in threaded view
|

Re: Quale formato?

Andrea Peri
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
Reply | Threaded
Open this post in threaded view
|

Re: Quale formato?

a.furieri
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
Reply | Threaded
Open this post in threaded view
|

Re: Quale formato?

Andrea Peri
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
Reply | Threaded
Open this post in threaded view
|

Re: Quale formato?

Maurizio Napolitano-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Quale formato?

Maurizio Trevisani
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
Reply | Threaded
Open this post in threaded view
|

Re: Quale formato?

Marco
In reply to this post by Andrea Peri
Andrea Peri wrote
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.
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.
Reply | Threaded
Open this post in threaded view
|

Re: Quale formato?

Sieradz
Marco wrote
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]

:)  
Reply | Threaded
Open this post in threaded view
|

Re: Quale formato?

Luca Lanteri
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.


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


_______________________________________________
[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
Reply | Threaded
Open this post in threaded view
|

Re: Quale formato?

Luca Lanteri
In reply to this post by pcav

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
Reply | Threaded
Open this post in threaded view
|

Re: Quale formato?

Marco
In reply to this post by Sieradz
Sieradz wrote
Premesso che le chiavi hardware viaggiavano su porta parallela (e non seriale)
[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.
Reply | Threaded
Open this post in threaded view
|

Re: Quale formato?

Andrea Peri
In reply to this post by Luca Lanteri
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
12