Hai capito perfettamente cosa intendevo quando parlavo di ripetibilita'.
E' il problema che ci siamo trovati a gestire con un famoso geodb di un
famoso software commerciale.
Il dato veniva spianato in una griglia, che nelle prime versioni era
quantizzata su valori interi, nelle versioni successive era quantizzata
su una griglia floating point, ma il concetto restava lo stesso.
Ovvero cambiando la griglia cambiava il risultato.
Se lo stesso dataset passava da due pc con due griglie differenti, e in
ognuna di esse semplicemente inserito una nuova linea, l'intero dataset
di riallineava sulla griglia di quel db e alla fine di aveva dataset che
sulla carta dovevano essere ufguali salvo leggeri cambiamenti
localizzati, ma che in realt'a presentavano differente micrometriche
ovunque.
Questi archivi quando si andava a rimetterli insieme generavano casini
impensabili.
Altro che soluzione per risolvere problemi, era la strada per incasinare
sempre di piu'.
E' sempre la teoria del calcio al barattolo.
PEr semplificare un problema locale (la precisione finita su un problema
di geometria) si sposta il problema a un altro livello , permettendo
l'esistenza di dati che possono cambiare griglia a seconda del pc da cui
passano.
Anche ora esisteuna griglia, ma e' quella fisica dettata dalla
precisione finita del pc ovvero a FloatingPoint a 64 bit.
Ed e' uguale su tutti i comuter.
Il fatto che sia uguale su tutti i computer vuol dire che il dato che
passa su tutti i computer resta empre uguale.
Ovviamente poi dipende da cio' che fa' l'utente , da che algoritmi
utilizza, che software.
Ma quello e' un altro discorso.
Qui si sta parando di qualcoa che anche in caso di medesimo algoritmo,
basta che adottiuna griglia differente che propone risultati differenti.
Brrrrr.
A.
Il 01/10/2015 22:39, a.furi...@lqt.it ha scritto:
On Thu, 1 Oct 2015 21:37:16 +0200, Sandro Santilli wrote:
Non mi sembra assurdo pensare di avere una griglia di riferimento
valida per tutti, per un determinato dataset.
Faccio un esempio: per la cartografia in scala 1:250000, usare una
griglia
di precisione millimetrica.
qua pero' si apre un oceano buio e procelloso.
personalmente sono abbastanza d'accordo sulla potenziale
utilita' di introdurre un fattore di approssimazione
"quasi infinitesimo", tipo il centomillesimo di centimetro
che citavi nell'altra tua mail.
puo' realisticamente servire per occultare le bizzarrie
piu' stravaganti del processore HW floating point, dei
flags piu' esoterici del compilatore e delle librerie
di runtime (magari subdolamente inlined e/o basate sul
set di istruzioni SSE per efficienza).
invece ipotizzare p.es. un millimetro per una determinata
scala 1:250000 ci porta dritti sparati dentro ai peggiori
scenari che Andrea ha cercato di ipotizzare per mettere
in guardia contro gli ovvi trappoloni che aspettano gli
incauti lungo il cammino.
a te pare ragionevole 1mm, a me personalmente pare meglio
0.5mm, Andrea preferisce 0.0000001mm e magari qualche
utente sprovveduto potrebbe pensare che 5m sarebbe ancora
meglio.
troppo facile prevedere una ricca fioritura di scelte
assolutamente disparate e dettate piu' che altro dal
caso (e magari per nulla documentate nei metadati che
pure dovrebbero accompgnare qualsiasi dataset, e che
invece troppo spesso sono degli illustri sconosciuti).
mettiti un po' nei panni di chi poi si trovera' in fondo
alla filiera a cercare disperatamente di integrare in modo
robustamente consistente tanti dataset di origine diversa
(p.es. comuneA/comuneB/comuneC/provA/provB/regione/stato,
agenzia x, sopraintendenza y, azienda z e cosi' via).
ciascuno dei quali avra' verosimilmente utilizzato una
propria griglia di snap con un passo diverso da tutti
gli altri.
pare uno scenario che non preannuncia nulla di buono :-D
ciao Sandro
_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni
dell'Associazione GFOSS.it.
786 iscritti al 30.9.2015
