[Gfoss] Quale formato?

[Andrea Peri]

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

Il 09/nov/2014 15:30 <a.furieri a lqt.it> 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
>
> _______________________________________________
> Gfoss a lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
dell'Associazione GFOSS.it.
> 666+40 iscritti al 5.6.2014
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.gfoss.it/pipermail/gfoss/attachments/20141109/f37ac38e/attachment.html>