[Gfoss] compilare QGIS-master su linux

Quella che citi e' la cosidetta "teoria della propagazione dell'errore".
L'errore in ogni sistema ad aritmetica finita e' quantificabile , e in base a come disponi le operazioni puoi ridurlo.

A scuola ci insegnano che in matematica vale il principio della commutazione su certe operazioni.

Per cui:

A + B = B *a

Questo principio non vale in senso generale in un mondo ad aritmetica finita.
Proprio a causa della propagazione dell'errore.

Se te fai:

(A * B) / C
in aritmentica finita non ' uguale a fare
A * (B / C)

proprio a causa della propagazione dell'errore.

E si riesce a dimostrare di quanto si scostano i due valori.

Per cui quando devi impostare un algoritmo per svolgere un calcolo di precisione, devi stare attento a come imposti le formule nel linguaggio di programmazione proprio per minimizzare l'errore.

Nella teoria della propagazione dell'errore uno dei capisaldi e' che meglio operare su numeri grandi piuttosto che su numeri piccoli.

Per questo suggeriscono di togliere la virgola.

Si moltiplica per 10.000 , abbassando la virgola di 4 posti.
Si effettuano i conti e poi si divide per una cifra come ad esempio 10.000 (sara' composta di un n.ro di cifre differenti in base al tipo di operazione svolte) per riportare la virgola al suo posto.
In quesotmodo si minimizza la propagazione dell'errore.

Senza dimenticare di impostare la formula commutandola in modo da minimizzare l'errore.

Ed e' tutta roba che non fa' perdere assolutamente un bit di precisione.

A.

Il 01/10/2015 21:37, Sandro Santilli ha scritto:

All'istituto che ho frequentato avevo una materia che si chiamava
"misure". Mi hanno insegnato a calcolare l'errore sulle misure e
come le varie operazioni li amplificano.
Gli elementi magari sono 10 ± 2, se la risposta e' consona.

A quanti metri si trova Firenze dal livello del mare ?
Quanto lontana dalla costa e' quella nave ?
Che area ha quella piazza ?

Si parla di modelli, devono essere utili, gestibili.

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@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 :smiley:

ciao Sandro

Sarebbe l’uovodi colombo.

Se uno si immaginasse la potenza elaborativa della topologia ISO, poi non la abbandonerebbe piu’.
Il problema e’ che propone un approccio completamente differente.
Un approccio che richiede anche un ripensamento delle metodiche di editing.
Soluzioni molto meno intuitive di un approccio simple-feature.

E’ come paragonare un elicottero a un aereo.

L’aereo e’ piu’ semplice come movimento e quindi piu’ veloce, l’efficienza si risolve nella velocita’.

L’elicottero e’ molto piu’ sofisticato e versatile perche’ puo’ fare dei movimenti che l’aereo non puo’ fare.
Molto piu’ agile, ma meno veloce, perche’ ha un movimento piu’ complesso ed e’ molto piu’ difficile da guidare perche’ l’operatore deve contemporaneamente muovere due rotori indipendenti.

A.

···

Il 01/10/2015 23:37, G. Allegri ha scritto:

Domanda piccola piccola: ma perché non si persegue l’approccio con la coppia modello geometrico/modello topologico? Capisco che sia più complesso e oneroso da gestire e mantenere rispetto ad una pseudotopologia, ma evita d’infognarsi nei meandri delle precisioni.
So che, come Postgis, anche Spatialite lo sta implementando (grazie a Regione Toscana). Continuo a sperare che prima o poi QGIS implementerà i meccanismi in grado di usufruire di questa doppia natura…

giovanni

Il 01/ott/2015 22:54, “Sandro Santilli” <strk@keybit.net> ha scritto:

On Thu, Oct 01, 2015 at 10:39:50PM +0200, a.furieri@lqt.it wrote:

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.

Potrei prendere un’abbaglio, ma ho l’impressione che, matematicamente
parlando, applicando la griglia meno fitta tra tutte quelle utilizzate
comporterebbe un matching esatto dei vari dataset.

Semmai il problema sara’ il trovare la griglia applicata ad ognuno
dei dataset, se non si conta sui metadata. E’ per quello che parlavo
di “griglie standard di riferimento”. Potrebbe essere un riferimento
normativo.

–strk;


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

Ri-intervengo giusto per una correzione di dettaglio.

Erroneamente ho parlato di principio commutativo.
In realta' nell'aritmetica finita viene negato il principio distributivo e non quello commutativo.
Forse anche quello commutativo, ci dovrei riflettere un po', ma in ogni caso quello che impiegavo nell'asserzione

(A*B)/C <> A*(B/C)

e' il principio distributivo.

A.

Il 01/10/2015 23:58, aperi2007 ha scritto:

A scuola ci insegnano che in matematica vale il principio della commutazione su certe operazioni.

Per cui:

A + B = B *a

Questo principio non vale in senso generale in un mondo ad aritmetica finita.
Proprio a causa della propagazione dell'errore.

Se te fai:

(A * B) / C
in aritmentica finita non ' uguale a fare
A * (B / C)

In pratica sogno un sistema robusto quanto un GRASS (o il vecchio ArcInfo) ma con una UX più semplice. La quadratura del cerchio :slight_smile:
Un bell’argomento di ricerca…

giovanni

Il 02/ott/2015 00:30, “aperi2007” <aperi2007@gmail.com> ha scritto:

Ri-intervengo giusto per una correzione di dettaglio.

Erroneamente ho parlato di principio commutativo.
In realta’ nell’aritmetica finita viene negato il principio distributivo e non quello commutativo.
Forse anche quello commutativo, ci dovrei riflettere un po’, ma in ogni caso quello che impiegavo nell’asserzione

(AB)/C <> A(B/C)

e’ il principio distributivo.

A.

Il 01/10/2015 23:58, aperi2007 ha scritto:

A scuola ci insegnano che in matematica vale il principio della commutazione su certe operazioni.

Per cui:

A + B = B *a

Questo principio non vale in senso generale in un mondo ad aritmetica finita.
Proprio a causa della propagazione dell’errore.

Se te fai:

(A * B) / C
in aritmentica finita non ’ uguale a fare
A * (B / C)


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

2015-10-02 0:38 GMT+02:00 G. Allegri <giohappy@gmail.com>:

In pratica sogno un sistema robusto quanto un GRASS (o il vecchio ArcInfo)
ma con una UX più semplice. La quadratura del cerchio :slight_smile:

beh dai molti passi in avanti sono stati fatti:
- location wizard per aiutare gli utenti a creare la location
- diversi tool grafici quali: grafical modeler, interfaccia per stampa
sfruttando ps.map, tool per visualizzazioni avanzate
- possibilità di importare dati con sistemi di coordinate diverse da
quelle della location in uso (attualmente nella versione trunk)

Un bell'argomento di ricerca...

ovviamente sarebbe molto interessante avere anche altre
idee/soluzioni, ma poi ci vorrebbe qualcuno che la implementi :slight_smile:

giovanni

--
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

Scusa se approfitto vigliaccamente.
:slight_smile:

Non sono mai riuscito a comprendere bene cosa si potesse realmente fare con la topologia di grass.

Esiste un documento , un howto, un rfc che spiega un po' piu' addentro la parte topologica ?

La mia conoscenza della topologia di grass si ferma al fatto che quando carico uno shapefile , lui me lo scompone in polygon 0,1 e 2. Che va benissimo, per un certo tipo di uso, ma non per molti altri impieghi.
Non sono ancora riuscito a capire se invece riesco a gestire direttamente n editing a livello di topologia.

Per cui la mia impressione ad oggi e' che su grass si passa sempre da una simple-feature che si edita in qualche modo e poi si ricarica nella topologia di grass.

E quindi non sono mai riuscito a capire se si puo' e con qali comandi operare direttamente sulla topologia, inserendo , rimuovendo o spostando un arco o un nodo nella copertura topologica generata dal caricamento di uno shapefile di poligoni.

A.

Il 02/10/2015 00:52, Luca Delucchi ha scritto:

2015-10-02 0:38 GMT+02:00 G. Allegri <giohappy@gmail.com>:

In pratica sogno un sistema robusto quanto un GRASS (o il vecchio ArcInfo)
ma con una UX più semplice. La quadratura del cerchio :slight_smile:

beh dai molti passi in avanti sono stati fatti:
- location wizard per aiutare gli utenti a creare la location
- diversi tool grafici quali: grafical modeler, interfaccia per stampa
sfruttando ps.map, tool per visualizzazioni avanzate
- possibilità di importare dati con sistemi di coordinate diverse da
quelle della location in uso (attualmente nella versione trunk)

Un bell'argomento di ricerca...

ovviamente sarebbe molto interessante avere anche altre
idee/soluzioni, ma poi ci vorrebbe qualcuno che la implementi :slight_smile:

giovanni

On Thu, 1 Oct 2015 11:31:20 -0700 (MST), nformica wrote:

Ciao Roberto,
capisco che l'argomento è abbastanza complesso !
Ma proprio nell'ottica di capire un pò tutti qualcosa (... anche chi non
sviluppa/programma), ti sarebbe possibile spiegarci con parole più semplici
in cosa consiste la questione ??
Mi riferisco sopratutto, per chi è un semplice utente finale.

Nino,

ci provo io a sintetizzare (si fa per dire ...) i termini della
questione nella forma piu' liscia e semplice di cui sono capace.
(avviso in anticipo: non saro' breve perche' la materia e' di per
se abbastanza complicata).

sostanzialmente dietro ad un unica etichetta "topologia" si
celano due interpretazioni (e due modelli concettuali) che
differiscono tra di se in modo abbastanza radicale.

"vera topologia"
----------------
scordati immediatamente concetti come Point, Linestring e Polygon,
e dimenticati pure il concetto di layer.
quelle sono le rappresentazioni "simple feature" delle geometrie,
e non hanno nulla a che vedere con il modello adottato dalla
"vera topologia".

in una "vera topologia" hai semplicemente un'unica superficie
infinita sulla quale si appoggiano oggetti Node, Edge e Face;
- un Node e' un punto notevole in cui si incontrano due o piu' Edges
- un Edge e' un tratto di confine comune tra due Faces adiacenti
   (pensa p.es. al confine italo-austriaco inteso come un'unica linea
   comune ad entrambi gli Stati).
- una Face e' una superficie delimitata da un certo numero di Edges;
   anche una topologia completamente vuota comprende una Face che
   e' la "faccia universo", cioe' la superficie infinita stessa.
   pensa p.es. alla penisola Italiana come territorio compreso tra
   le linee di confine italo-francese, italo-svizzera, italo-austriaca,
   italo-slovena e la linea di costa; linea di costa che altro non
   e' che una linea di confine (=Edge) con un lato sulla face
   "penisola italiana" e l'altro lato sulla "face universe".
   Sicilia e Sardegna saranno altre due Faces ancora, e saranno
   semplicemente delimitate dalla linea di costa.
   e cosi' via per tutte le altre isole minori, ciascuna delle quali
   formera' una Face indipendente; poi avrai le due "isole interne"
   in corrispondenza della Citta' del Vaticno e di San Marino.
   impasta tutto assieme ed ottieni il territorio della Repubblica
   Italiana descritto nei termini "sbriciolati" di tanti Nodes, Edges
   e Faces.
   fisicamente non avrai *mai* disegnato neppure un poligono: avrai
   invece piazzato dei punti (Nodes) e tracciato delle linee (Edges,
   ossia tratti di confine); la dove uno o piu' Edges delimitano
   una superficie chiusa avrai automaticamente definito una Face
   e cosi' via.

ovviamente e' possibile creare una topologia a partire da un set
di Points/Linestrings/Polygons, ma per arrivarci serve tutta una fase
di validazione (generalmente lunga e pesante).
altrettanto ovviamente e' possibile ricavare Points, Linestrings e
Polygons da una topologia: ma ancora una volte serve una operazione
di trasformazione non del tutto banale.

naturalmente scordati di poter fare operazioni di editing tipo
"ho modificato l'Umbria"; per arrivare a quel risultato finale
dovrai sempre lavorare indirettamente sui vari Nodes/Edges che
delimitano la Face "Umbria", e solo alla fine di una sequenza piu'
o meno lunga di operazioni indirette sugli oggetti elementari della
topologia potrai materialmente "vedere" il frutto dei tuoi sforzi
a livello della regione nel suo complesso.
pero' in compenso sarai sempre tassativamente certo che le tue
modifiche si rifletteranno sempre con rigorosa simmetria anche
su tutte quante le regioni confinanti (Toscana, Lazio, Marche).
ed avrai un altro possibile bonus: se disegni le tue faces al
livello piu' basso possibile (p.es. comuni), qualsiasi modifica
dei confini si propaghera' automaticmanete anche a tutti i livelli
gerarchici superiori (usl, comunita' montana, circondario,
distretto, provincia, regione, stato etc).
tutto in modo totalmente automatico e del tutto trasparente.

un po' di storia: il modello "vera topologia" node-edge-face venne
inizialmente introdotto da ESRI ArcINFO (oggi non piu' disponibile);
continua invece ad essere attivamente supportato da GRASS GIS.
infine e' alla base del modello standard ISO/IEC 13249-3 (SQL MM),
ed in quest'ultima forma e' supportato da Oracle Spatial, da
PostGIS e prossimamente anche da SpatiaLite.

in parole spicciole: e' un approccio sicuramente "complicato",
abbastanza diverso dal classico "modello shapefile" che e' quello
probabilmente piu' familiare per te e per tantissimi altri.
altrettanto sicuramente e' un approccio robusto, solido, rigoroso,
supportato da una ricca teoria matematica alle spalle, ma soprattutto
e' qualcosa che e' stato minuziosamente codificato e definito
formalmente da uno standard di livello internazionale.

"simil topologia" aka "topologia semplificata"
-----------------------------------------------
qualcosa di apparentemente simile si puo' ottenere in un modo
molto piu' semplice e facile da implementare.
basta introdurre semplicemente una griglia di snap obbligatoria
basata su celle di dimensioni a tua scelta: i punti ed i vertici
potranno stare solo *esattamente* la dove di trova un nodo della
griglia di riferimento.
se non e' cosi', ci pensera' il sw a spostare il punto sulla
posizione fissa piu' vicina.
(se vuoi, pensa al disegno col lapis sulla carta millimetrata:
devi sempre centrare un punto di incontro tra linea verticale
e linea orizzontale per potere piazzare un punto/vertice ... se
lo piazzi appena un po' spostato funzionera' come una magica
calamita che te lo riporta automaticamente nella posizione "giusta")

bloccare le posizioni disponibili ad una griglia fissa piu' o
meno densa semplifica notevolmente il compito di stabilire se
due segmenti presi a caso sono realmente un'unica cosa oppure
due cose distinte, e quindi in ultima analisi semplifica il
compito di assicurare che due poligoni adiacenti "si tocchino"
in modo topologico corretto (cioe' senza sovrapposizioni e
senza neppure lasciare antipatiche striscioline "terra di
nessuno").

il modello concettuale "simil topologia via griglia" e' stato
inizialmente introdotto da ESRI ArcGIS sui suoi GeoDatabase.
ha il vantaggio che e' certamente meno "esoterico" dell'altro
modello node-edge-face, e sostanzialmente consente di continuare
ad utilizzare praticamente invariati quei concetti di layer
point/linestring/polygon cosi' rassicurantemente familiari
per tantissimi utenti.
naturalmente nella vita non esistono pasti gratis; qualsiasi
compromesso richiede inevitabilmente un qualche prezzo da pagare.

in questo caso quel che si guadagna in termini di apparente
semplicita' e facilita' d'uso lo si perde simmetricamente in
termini di robustezza e rigorosa consistenza.
e soprattutto lo si perde in termini di interscambio dati;
finira' inevitabilmente che ciascun utente/ente usera' le
proprie griglie definite a suo gusto personale, che mal si
adatteranno alle altre gliglie con passo diverso utilizzate
da altri utenti/enti.

un abbozzo di conclusione
-------------------------
non e' certo per caso se negli ambienti professionali high-end
si e' sempre preferito utilizzare un ben noto (e costoso)
Spatial DBMS proprietario basato su ISO 13249-3 per fare
topologia "seria".
oggi finalmente anche il sw GFOSS inizia ad essere in grado
di supportare decentemente bene ISO 13249-3; lo fa gia' oggi
PostGIS e lo fara' molto presto anche SpatiaLite, e tutto
sommato lo fa fin dalla notte dei tempi pure GRASS GIS che
comunque adotta un modello conforme Node-Edge-Face pur essendo
nato ben prima che vedesse la luce la specifica ISO 13249-3
tutti e tre assieme possoono utilmente cooperare e fare
intelligentemente qualche tipo di cross-impollinazione
spalleggiandosi a vicenda, visto che il modello concettuale
di riferimento e' sempre il solito.

proprio per questo pare decisamente in controtendenza andare
invece a cercare di recuperare l'altro approccio "via griglia"
che e' oggettivamente inferiore sotto un profilo puramente
tecnico e che oltre tutto non e' neppure supportato da uno
straccio di standard formale.

una volta tanto e' il sw FLOSS/GFOSS che guida saldamente la
corsa ben piazzato nel ristrettissimo plotoncino di testa;
noi siamo in grado di offrire fin da oggi la soluzione piu'
robusta e completa, quella che poggia su solide basi matematiche
e che e' rigorosamente conforme agli standard internazionali.
il nostro principale competitor proprietario oggi come oggi
non dispone di nessuna alternativa valida da mettere in campo;
ce l'aveva in anni passati, ma per sua libera scelta ha
preferito rottamarla (lasciandosi cosi' alle spalle non pochi
orfani e vedovi inconsolabili)
sarebbe veramente un grosso abbaglio cercare di inseguirlo sul
suo stesso terreno quando invece abbiamo tutto quel che serve
per sorpassarlo a pieni giri :smiley:

ciao Sandro

Il 02/10/2015 01:02, aperi2007 ha scritto:

Non sono ancora riuscito a capire se invece riesco a gestire
direttamente n editing a livello di topologia.

Per cui la mia impressione ad oggi e' che su grass si passa sempre da
una simple-feature che si edita in qualche modo e poi si ricarica nella
topologia di grass.

E quindi non sono mai riuscito a capire se si puo' e con qali comandi
operare direttamente sulla topologia, inserendo , rimuovendo o spostando
un arco o un nodo nella copertura topologica generata dal caricamento di
uno shapefile di poligoni.

Salve.
GRASS opera direttamente in topologia. Per capirci di piu', forse la
cosa piu' semplice e' leggere il log del plugin, che durante una fase di
importazione descrive minuziosamente come scompone una simple geometry e
la ricostruisce in una topogeom.
Il nuovo plugin per G7 ha un sistema di editing topologico completamente
rifatto, se vuoi provalo, cosi' ci aiuti anche a scoprire i possibili bugs.
Saluti.

--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html

2015-10-02 1:02 GMT+02:00 aperi2007 <aperi2007@gmail.com>:

Scusa se approfitto vigliaccamente.
:slight_smile:

ci mancherebbe

Non sono mai riuscito a comprendere bene cosa si potesse realmente fare con
la topologia di grass.

Esiste un documento , un howto, un rfc che spiega un po' piu' addentro la
parte topologica ?

qui [0] trovi la spiegazione della topologia in GRASS, qui [1] come è
stato realizzato il bridge tra la topologia di PostGIS e quella di
GRASS (grazie al finanziamento del Comune di Trento) sarebbe bello
poter fare lo stesso quando Spatialite supporterà anch'esso la
topologia :slight_smile:

La mia conoscenza della topologia di grass si ferma al fatto che quando
carico uno shapefile , lui me lo scompone in polygon 0,1 e 2. Che va
benissimo, per un certo tipo di uso, ma non per molti altri impieghi.

che cosa intendi per "polygon 0,1 e 2" ?

Non sono ancora riuscito a capire se invece riesco a gestire direttamente n
editing a livello di topologia.

Per cui la mia impressione ad oggi e' che su grass si passa sempre da una
simple-feature che si edita in qualche modo e poi si ricarica nella
topologia di grass.

scusa andrea non mi è molto chiara questa parte...

E quindi non sono mai riuscito a capire se si puo' e con qali comandi
operare direttamente sulla topologia, inserendo , rimuovendo o spostando un
arco o un nodo nella copertura topologica generata dal caricamento di uno
shapefile di poligoni.

tutti i comandi dei vettoriali lavorano a livello topologico, e anche
il digitalizzatore [2]

A.

[0] https://grass.osgeo.org/programming7/vlibTopology.html
[1] https://grasswiki.osgeo.org/wiki/PostGIS_Topology
[2] https://grass.osgeo.org/grass71/manuals/wxGUI.vdigit.html

--
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

@Luca sono stati fatti grandi passi in avanti nell’usabilità di GRASS con la nuova UI (ormai neanche tanto nuova). Resta però un sistema per “iniziati”. Io gli dedico sempre un discreto tempo nei miei corsi, ma è riprovato che i più preferiscano lavorare con QGIS e, al massimo, usufruire di GRASS tramite plugin o Processing. Questo è indicativo che l’esperienza utente resta più complessa rispetto ad altre soluzioni.

La mia cmq non è una critica, sia chiaro. Anzi, GRASS porta avanti novità sempre di grandissimo valore.

La quadratura del cerchio è tendere appunto a riunire UX e robustezza ovvero, in altra prospettiva, evitare che la complessità sia anche complicatezza.
In merito alla topologia, come dice Sandro, ESRI ha cercato questo sacro Graal abbandonando il modello ArcInfo e perseguendo un modello basato su un sistema avanzato di pseudotopologia la cui robustezza (interna) è data dell’approccio a griglia di precisione. Andrea ha esperienza da vendere in merito ai problemi che questo genera. Mi chiedo come faccia però ad essere leader anche in settori strategici e sensibili (come quello militare) se il suo approccio vi risulta così errato.

QGIS, che vince in semplicità di UX, propone una soluzione simile.
GRASS resta fedele. L’ammiro e resto favorevole alla scelta di GRASS, ma… (torna alla prima riga)

giovanni

Il 02/ott/2015 07:57, “Paolo Cavallini” <cavallini@faunalia.it> ha scritto:

Il 02/10/2015 01:02, aperi2007 ha scritto:

Non sono ancora riuscito a capire se invece riesco a gestire
direttamente n editing a livello di topologia.

Per cui la mia impressione ad oggi e’ che su grass si passa sempre da
una simple-feature che si edita in qualche modo e poi si ricarica nella
topologia di grass.

E quindi non sono mai riuscito a capire se si puo’ e con qali comandi
operare direttamente sulla topologia, inserendo , rimuovendo o spostando
un arco o un nodo nella copertura topologica generata dal caricamento di
uno shapefile di poligoni.

Salve.
GRASS opera direttamente in topologia. Per capirci di piu’, forse la
cosa piu’ semplice e’ leggere il log del plugin, che durante una fase di
importazione descrive minuziosamente come scompone una simple geometry e
la ricostruisce in una topogeom.
Il nuovo plugin per G7 ha un sistema di editing topologico completamente
rifatto, se vuoi provalo, cosi’ ci aiuti anche a scoprire i possibili bugs.
Saluti.


Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html


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

.... e si, è un'argomento alquanto complesso di cui spesso il GIS end-user
non è a conoscenza !
L'unica cosa che io sapevo già (... sbattendoci spesso) è che il modello
topologico dei vettori GRASS è diverso dal semplice Shapefile.

Ti ringrazio dello sforzo che hai fatto per spiegarcelo !!

Ciao !
Nino

--
View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/compilare-QGIS-master-su-linux-tp7594310p7594345.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.

PS: mi scuso per la frase su ESRI che potrebbe essere sembrata a qualcuno un po’ pubblicitaria. Non lo era affatto. Anzi, sono il primo a ritenere difettoso l’approccio di ESRI. La domanda però rimane: come fanno tanti settori che usano ESRI a convivere con questo approccio se risulta effettivamente difettoso? Penso al “catasto” americano, o all’IGM, ecc.

giovanni

···

Il giorno 2 ottobre 2015 08:44, G. Allegri <giohappy@gmail.com> ha scritto:

@Luca sono stati fatti grandi passi in avanti nell’usabilità di GRASS con la nuova UI (ormai neanche tanto nuova). Resta però un sistema per “iniziati”. Io gli dedico sempre un discreto tempo nei miei corsi, ma è riprovato che i più preferiscano lavorare con QGIS e, al massimo, usufruire di GRASS tramite plugin o Processing. Questo è indicativo che l’esperienza utente resta più complessa rispetto ad altre soluzioni.

La mia cmq non è una critica, sia chiaro. Anzi, GRASS porta avanti novità sempre di grandissimo valore.

La quadratura del cerchio è tendere appunto a riunire UX e robustezza ovvero, in altra prospettiva, evitare che la complessità sia anche complicatezza.
In merito alla topologia, come dice Sandro, ESRI ha cercato questo sacro Graal abbandonando il modello ArcInfo e perseguendo un modello basato su un sistema avanzato di pseudotopologia la cui robustezza (interna) è data dell’approccio a griglia di precisione. Andrea ha esperienza da vendere in merito ai problemi che questo genera. Mi chiedo come faccia però ad essere leader anche in settori strategici e sensibili (come quello militare) se il suo approccio vi risulta così errato.

QGIS, che vince in semplicità di UX, propone una soluzione simile.
GRASS resta fedele. L’ammiro e resto favorevole alla scelta di GRASS, ma… (torna alla prima riga)

giovanni

Il 02/ott/2015 07:57, “Paolo Cavallini” <cavallini@faunalia.it> ha scritto:

Il 02/10/2015 01:02, aperi2007 ha scritto:

Non sono ancora riuscito a capire se invece riesco a gestire
direttamente n editing a livello di topologia.

Per cui la mia impressione ad oggi e’ che su grass si passa sempre da
una simple-feature che si edita in qualche modo e poi si ricarica nella
topologia di grass.

E quindi non sono mai riuscito a capire se si puo’ e con qali comandi
operare direttamente sulla topologia, inserendo , rimuovendo o spostando
un arco o un nodo nella copertura topologica generata dal caricamento di
uno shapefile di poligoni.

Salve.
GRASS opera direttamente in topologia. Per capirci di piu’, forse la
cosa piu’ semplice e’ leggere il log del plugin, che durante una fase di
importazione descrive minuziosamente come scompone una simple geometry e
la ricostruisce in una topogeom.
Il nuovo plugin per G7 ha un sistema di editing topologico completamente
rifatto, se vuoi provalo, cosi’ ci aiuti anche a scoprire i possibili bugs.
Saluti.


Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html


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

Giovanni Allegri
http://about.me/giovanniallegri
Gis3W - http://gis3w.it
Ikare - http://ikare.it

Twitter: https://twitter.com/giohappy
blog: http://blog.spaziogis.it
GEO+ geomatica in Italia http://bit.ly/GEOplus

L'approccio adottato dalla societa' che citi non e' difettoso.
Anzi tecnicamente e' interessante.

E' una scelta implementativa ben precisa.

Con vantaggi e svantaggi.
Si tratta di pesare gli uni e gli altri avendoli ben presente.

Ottimizza lo spazio disco occupato e garantisce velocita'.

una griglia di interi usata per quantizzare valori in virgola mobile
permette di fare determinati calcoli (non tutti ovviamente) in intero.
E i processori sono diversi ordini di grandezza piu' veloci con i
numeri interi piuttosto che con i numeri in FP64.

Anche in presenza di un coprocessore matematico (da decenni ormai
presente su ogni CPU, salvo forse quelle dei netcomputers)

Non ne sono certissimo, ma probabilmente anche una griglia di valori
FP permette di realizzare delle ottimizzazioni sullo spazio disco e
sulle performance.

Queste sono consierazioni significative specie se seiin una situazione
dove un leggerissimo spostamento di pochi millimetri e' irrilevante.

E infatti la replica usuale era che a fronte di dati che scontano
errori di precisione di qualche metro uno spostamento di qualche
millimetro e' irrilevante.

E questo puo' essere anche vero finche' si resta su un singolo sistema
elaborativo.

Oggi pero' e' presente anche un discorso di interoperabilita' e per
questo e' importante poter replicare i medesimi comportamenti in altri
sistemi differenti. Per questo la persisnteza del dato e' un parametro
non piu' trascurabile anche se si tratta di pochissimi millimetri.

Quindi dipende dal caso di uso a cui si applica il dato.
Per questo e' importante preservare la versatilit'a di impiego e
quindi puntare a tenere il piu' possibile inalterato il dato
originale.

Proprio perche' non sai mai per cosa potra' essere usato in futuro.

Ed e' per questo che ho visto subito nubi fosche quanto ho letto di
QGIS e della ipotesi della griglia.

A.

Il 2 ottobre 2015 10:39, G. Allegri <giohappy@gmail.com> ha scritto:

PS: mi scuso per la frase su ESRI che potrebbe essere sembrata a qualcuno un
po' pubblicitaria. Non lo era affatto. Anzi, sono il primo a ritenere
difettoso l'approccio di ESRI. La domanda però rimane: come fanno tanti
settori che usano ESRI a convivere con questo approccio se risulta
effettivamente difettoso? Penso al "catasto" americano, o all'IGM, ecc.

giovanni

Il giorno 2 ottobre 2015 08:44, G. Allegri <giohappy@gmail.com> ha scritto:

@Luca sono stati fatti grandi passi in avanti nell'usabilità di GRASS con
la nuova UI (ormai neanche tanto nuova). Resta però un sistema per
"iniziati". Io gli dedico sempre un discreto tempo nei miei corsi, ma è
riprovato che i più preferiscano lavorare con QGIS e, al massimo, usufruire
di GRASS tramite plugin o Processing. Questo è indicativo che l'esperienza
utente resta più complessa rispetto ad altre soluzioni.

La mia cmq non è una critica, sia chiaro. Anzi, GRASS porta avanti novità
sempre di grandissimo valore.

La quadratura del cerchio è tendere appunto a riunire UX e robustezza
ovvero, in altra prospettiva, evitare che la complessità sia anche
complicatezza.
In merito alla topologia, come dice Sandro, ESRI ha cercato questo sacro
Graal abbandonando il modello ArcInfo e perseguendo un modello basato su un
sistema avanzato di pseudotopologia la cui robustezza (interna) è data
dell'approccio a griglia di precisione. Andrea ha esperienza da vendere in
merito ai problemi che questo genera. Mi chiedo come faccia però ad essere
leader anche in settori strategici e sensibili (come quello militare) se il
suo approccio vi risulta così errato.

QGIS, che vince in semplicità di UX, propone una soluzione simile.
GRASS resta fedele. L'ammiro e resto favorevole alla scelta di GRASS,
ma... (torna alla prima riga)

giovanni

Il 02/ott/2015 07:57, "Paolo Cavallini" <cavallini@faunalia.it> ha
scritto:

Il 02/10/2015 01:02, aperi2007 ha scritto:

> Non sono ancora riuscito a capire se invece riesco a gestire
> direttamente n editing a livello di topologia.
>
> Per cui la mia impressione ad oggi e' che su grass si passa sempre da
> una simple-feature che si edita in qualche modo e poi si ricarica nella
> topologia di grass.
>
> E quindi non sono mai riuscito a capire se si puo' e con qali comandi
> operare direttamente sulla topologia, inserendo , rimuovendo o
> spostando
> un arco o un nodo nella copertura topologica generata dal caricamento
> di
> uno shapefile di poligoni.

Salve.
GRASS opera direttamente in topologia. Per capirci di piu', forse la
cosa piu' semplice e' leggere il log del plugin, che durante una fase di
importazione descrive minuziosamente come scompone una simple geometry e
la ricostruisce in una topogeom.
Il nuovo plugin per G7 ha un sistema di editing topologico completamente
rifatto, se vuoi provalo, cosi' ci aiuti anche a scoprire i possibili
bugs.
Saluti.

--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
_______________________________________________
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

--
Giovanni Allegri
http://about.me/giovanniallegri
Gis3W - http://gis3w.it
Ikare - http://ikare.it
Twitter: https://twitter.com/_giohappy_
blog: http://blog.spaziogis.it
GEO+ geomatica in Italia http://bit.ly/GEOplus

_______________________________________________
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

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

Il 02/10/2015 11:34, Andrea Peri ha scritto:

L'approccio adottato dalla societa' che citi non e' difettoso.
Anzi tecnicamente e' interessante.

Salve.
Scusate per la pedanteria, fatta nell'interesse generale: quando la
discussione diverge dal tema originale, per piacere cambiate l'oggetto
della mail, per miglior leggibilita' ed archiviazione.
Grazie mille.

--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html

2015-10-02 8:44 GMT+02:00 G. Allegri <giohappy@gmail.com>:

@Luca sono stati fatti grandi passi in avanti nell'usabilità di GRASS con la
nuova UI (ormai neanche tanto nuova). Resta però un sistema per "iniziati".
Io gli dedico sempre un discreto tempo nei miei corsi, ma è riprovato che i
più preferiscano lavorare con QGIS e, al massimo, usufruire di GRASS tramite
plugin o Processing. Questo è indicativo che l'esperienza utente resta più
complessa rispetto ad altre soluzioni.

si lo so, però sarebbe interessante capire il perchè, a me non sembra
complessa (anche se non la uso mai :slight_smile: )

La mia cmq non è una critica, sia chiaro. Anzi, GRASS porta avanti novità
sempre di grandissimo valore.

beh ma le critiche costruttive sono sempre ben accette, bisognerebbe
capire perchè e cosa impaurisce gli utenti....

giovanni

--
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

Il 02/10/2015 11:42, Luca Delucchi ha scritto:

si lo so, però sarebbe interessante capire il perchè, a me non sembra
complessa (anche se non la uso mai :slight_smile: )

beh ma le critiche costruttive sono sempre ben accette, bisognerebbe
capire perchè e cosa impaurisce gli utenti....

secondo me un fattore importante e' che a pochi piace saltare da un
programma all'altro: la maggior parte avvia QGIS, e preferisce fare
tutto da li'.
le ultime volte che ho provato ho trovato che mi ci volevano piu' click
dello stretto necessario per fare operazioni semplici, tipo visualizzare
un raster.
hope this helps.
saluti.

--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html

2015-10-02 11:54 GMT+02:00 Paolo Cavallini <cavallini@faunalia.it>:

Il 02/10/2015 11:42, Luca Delucchi ha scritto:

si lo so, però sarebbe interessante capire il perchè, a me non sembra
complessa (anche se non la uso mai :slight_smile: )

beh ma le critiche costruttive sono sempre ben accette, bisognerebbe
capire perchè e cosa impaurisce gli utenti....

secondo me un fattore importante e' che a pochi piace saltare da un
programma all'altro: la maggior parte avvia QGIS, e preferisce fare
tutto da li'.

questo lo capisco, infatti

le ultime volte che ho provato ho trovato che mi ci volevano piu' click
dello stretto necessario per fare operazioni semplici, tipo visualizzare
un raster.

ho fatto una prova molto veloce:
visualizzare un raster da gui: GRASS 4 click, QGIS 3 click
visualizzare un vector da gui: GRASS 4 click, QGIS 4 click
visualizzare entrambi da console 0 click :wink:

non mi sembra un grosso problema 1 click di differenza...

hope this helps.
saluti.

--
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org

Il 02/10/2015 12:00, Luca Delucchi ha scritto:

ho fatto una prova molto veloce:
visualizzare un raster da gui: GRASS 4 click, QGIS 3 click
visualizzare un vector da gui: GRASS 4 click, QGIS 4 click
visualizzare entrambi da console 0 click :wink:

non mi sembra un grosso problema 1 click di differenza...

dal browser e' un solo doppio click, questo fa la differenza IMHO
saluti

--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html

Luca Delucchi wrote

beh ma le critiche costruttive sono sempre ben accette, bisognerebbe
capire perchè e cosa impaurisce gli utenti....

Paolo Cavallini wrote

secondo me un fattore importante e' che a pochi piace saltare da un
programma all'altro: la maggior parte avvia QGIS, e preferisce fare
tutto da li'.

Anche se uso maggiormente QGIS, per tante cose preferisco GRASS e lo ritengo
insostituibile.
Ma oltre a confermare quello che dice Paolo (.. la maggioranza delle persone
preferisce usare un solo SW), riportando le sensazioni di tanti utenti che
incontro o nei corsi o nell'ambiente di lavoro, non c'è dubbio che GRASS è
meno user-friendly !! Tanto per dirti due aspetti al volo, che frenano:
-) il dover scegliere e definire la "location" in cui operare;
-) l' IDE fatta di due finestre separate.

Lo so ... lo so, sono delle stupidaggini !! Ma per l'utente comune medio
sono queste piccole differenze di approccio che possono fare la differenza.
Detto ciò, non c'è dubbio che GRASS resta un grande GIS !!

Ciao !
Nino

--
View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/compilare-QGIS-master-su-linux-tp7594310p7594371.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.