compilare QGIS-master su linux

classic Classic list List threaded Threaded
48 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: compilare QGIS-master su linux

Andrea Peri
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.

_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: compilare QGIS-master su linux

Andrea Peri
In reply to this post by a.furieri
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, [hidden email] 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
>
>
>
>

_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: compilare QGIS-master su linux

Andrea Peri
In reply to this post by giohappy
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" <[hidden email]> ha scritto:
On Thu, Oct 01, 2015 at 10:39:50PM +0200, [hidden email] 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;
_______________________________________________
[hidden email]
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


_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: compilare QGIS-master su linux

Andrea Peri
In reply to this post by Andrea Peri
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)

_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: compilare QGIS-master su linux

giohappy

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

giovanni

Il 02/ott/2015 00:30, "aperi2007" <[hidden email]> 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

(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)

_______________________________________________
[hidden email]
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

_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: compilare QGIS-master su linux

Luca Delucchi
2015-10-02 0:38 GMT+02:00 G. Allegri <[hidden email]>:
> In pratica sogno un sistema robusto quanto un GRASS (o il vecchio ArcInfo)
> ma con una UX più semplice. La quadratura del cerchio :)

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 :-)

> giovanni
>

--
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: compilare QGIS-master su linux

Andrea Peri
Scusa se approfitto vigliaccamente.
:)

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 <[hidden email]>:
>> In pratica sogno un sistema robusto quanto un GRASS (o il vecchio ArcInfo)
>> ma con una UX più semplice. La quadratura del cerchio :)
> 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 :-)
>
>> giovanni
>>

_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: compilare QGIS-master su linux

a.furieri
In reply to this post by nformica
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 :-D

ciao Sandro

_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: compilare QGIS-master su linux

pcav
In reply to this post by Andrea Peri
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
_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: compilare QGIS-master su linux

Luca Delucchi
In reply to this post by Andrea Peri
2015-10-02 1:02 GMT+02:00 aperi2007 <[hidden email]>:
> Scusa se approfitto vigliaccamente.
> :)
>

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 :-)

> 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
_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: compilare QGIS-master su linux

giohappy
In reply to this post by pcav

@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" <[hidden email]> 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
_______________________________________________
[hidden email]
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

_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: compilare QGIS-master su linux

nformica
In reply to this post by a.furieri
....  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
Reply | Threaded
Open this post in threaded view
|

Re: compilare QGIS-master su linux

giohappy
In reply to this post by giohappy
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 <[hidden email]> 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" <[hidden email]> 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
_______________________________________________
[hidden email]
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



--

_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: compilare QGIS-master su linux

Andrea Peri
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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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
>>> _______________________________________________
>>> [hidden email]
>>> 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
>
> _______________________________________________
> [hidden email]
> 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 àèìòù
-----------------
_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Oggetto appropriato alla discussione (era: compilare QGIS-master su linux)

pcav
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
_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: compilare QGIS-master su linux

Luca Delucchi
In reply to this post by giohappy
2015-10-02 8:44 GMT+02:00 G. Allegri <[hidden email]>:
> @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 :-) )

> 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
_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: compilare QGIS-master su linux

pcav
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 :-) )

> 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
_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: compilare QGIS-master su linux

Luca Delucchi
2015-10-02 11:54 GMT+02:00 Paolo Cavallini <[hidden email]>:

> 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 :-) )
>
>> 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 ;-)

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
_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: compilare QGIS-master su linux

pcav
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 ;-)
>
> 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
_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: compilare QGIS-master su linux

nformica
In reply to this post by Luca Delucchi
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
123