[Gfoss] compilare QGIS-master su linux

[aperi2007]

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