compilare QGIS-master su linux
Locked
123
123
Re: 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. _______________________________________________ [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 |
Re: compilare QGIS-master su linux
|
|
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 |
Re: compilare QGIS-master su linux
|
|
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:
_______________________________________________ [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 |
Re: compilare QGIS-master su linux
|
|
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 |
|
|
In pratica sogno un sistema robusto quanto un GRASS (o il vecchio ArcInfo) ma con una UX più semplice. La quadratura del cerchio :) giovanni Il 02/ott/2015 00:30, "aperi2007" <[hidden email]> ha scritto:
Ri-intervengo giusto per una correzione di dettaglio. _______________________________________________ [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 |
Re: compilare QGIS-master su linux
|
|
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 |
Re: compilare QGIS-master su linux
|
|
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 |
|
|
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 |
|
|
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 |
Re: compilare QGIS-master su linux
|
|
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 |
|
|
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. QGIS, che vince in semplicità di UX, propone una soluzione simile. giovanni Il 02/ott/2015 07:57, "Paolo Cavallini" <[hidden email]> ha scritto:
Il 02/10/2015 01:02, aperi2007 ha scritto: _______________________________________________ [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 |
|
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 |
|
|
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:
Giovanni Allegri http://about.me/giovanniallegri Gis3W - http://gis3w.it _______________________________________________ [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 |
Re: compilare QGIS-master su linux
|
|
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 |
|
|
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 |
Re: compilare QGIS-master su linux
|
|
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 |
|
|
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 |
Re: compilare QGIS-master su linux
|
|
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 |
|
|
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 |
|
|
In reply to this post by Luca Delucchi
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 |
«
Return to Gfoss -- Geographic Free and Open Source Software - Italian mailing list
|
1 view|%1 views
| Free forum by Nabble | Edit this page |