[Gfoss] Quale formato?

[a.furieri a lqt.it]

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