Gis e Cad3D
Locked
12345
12345
 
|
Il giorno 23/gen/2014, alle ore 10:59, antoniovinci <[hidden email]> ha scritto:
> Caro Marco, > l'equivalenza qualitativa di un modello 3D raster rispetto ad uno vettoriale > (come tu sostieni) è tecnicamente priva di ogni fondamento, Va beh. :) > poichè fra i 2 > mondi c'è (almeno) un ordine di grandezza di differenza di precisione. Ari-vabeh :) Io sto parlando di rappresentazione di dati geografico/territoriali, visto l'argomento della ML, non di dati "attratti" ne' di geometria pura. Anche io potrei farti tanti esempi, di fronte ad una birra e magari con un foglio e una matita, cercando di portare il ragionamento sulla precisione dei punti di coordinate note (e cosa significa "coordinate note") e sulla quantizzazione dell'informazione. Mi sembra pero' che parliamo due lingue completamente diverse, quindi è inutile che stiamo a discutere, tanto va a finire che ci innervosiamo inutilmente. E soprattutto, stavolta si', andiamo veramente OT rispetto alla ML. Quindi credo sia meglio non perseverare :) Ciao! Marco Marco Gualdrini GEOgrafica - Faenza ------------------------------------------------------------------------------- GEOgrafica - GIS, cartografia digitale e simulazioni territoriali virtuali www.geografica.org Virtual Terrain Project / GeoView examples: http://youtu.be/qEeGjNvwl4Y http://youtu.be/9UPfufPLQUw http://youtu.be/gv8HgX9TZfs ------------------------------------------------------------------------------- _______________________________________________ [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. 666 iscritti al 22.7.2013 |
|
|
In reply to this post by antoniovinci
Il giorno 23/gen/2014, alle ore 10:08, antoniovinci <[hidden email]> ha scritto: /si certo. Se si tratta di fare solo un calcolo di uno sbancamento o di un riporto, concettualmente il metodo e' semplice e direi molto pedestre: non si fa altro che trasformare la singola cella del raster in un prisma con base a quota X nota (quota inferiore a tutte le quote presenti sul DEM di partenza e di arrivo), quindi calcolare il volume prima e dopo e quindi la differenza. Poi si fa la sommatoria di tutte le celle et voila'. Il vantaggio dei raster e' che l'algebra coinvolta e' banale rispetto al vettoriale, visto che si raffrontano le due superfici cella per cella e si devono fare solo delle somme algebriche. Ovvio che la precisione del tutto e' funzione della dimensione della cella di rasterizzazione, come sempre con i raster. E' pero' altrettanto vero che la pretesa maggior precisione teorica di un modello vettoriale in questo tipo di calcoli non corrisponde ad una realtà concreta visto che qualunque modello a triangoli si basa comunque sulla definizione di vertici entro certi margini di errore, nonche' nella definizione di superfici (piane se parliamo di triangoli, curve se parliamo di subpatch) che sono comunque una astrazione matematica rispetto alla reale morfologia dell'oggetto rappresentato. La definizione di breaklines di raccordo attraverso cui, per esempio, si puo' eseguire una triangolazione di Delaunay potra' produrre un modello "piu' pulito", piu' "liscio" rispetto all'equivalente modello raster (ma solo se uso raster a bassa risoluzione...), ma questo non significa affatto che sia piu' preciso, visto che quello che realmente accade tra due vertici definiti in una mesh vettoriale e' eliso per definizione. Anche nel vettoriale si determina una quantizzazione del dato come nel raster, e quindi la precisione di un calcolo di volumi e' sempre relativa alla precisione del dato di partenza. Io per queste cose, concretamente all'atto pratico uso vari software con i quali faccio modellazione e progettazione (si tratta prevalentemente di software proprietari), comunque per approfondire i temi trattati in ambito OpenSource ti cito il solito GRASS con il modulo dei volumi 3D. Puoi guardare qui: e qui: ciao! Marco Gualdrini GEOgrafica - Faenza ------------------------------------------------------------------------------- GEOgrafica - GIS, cartografia digitale e simulazioni territoriali virtuali Virtual Terrain Project / GeoView examples: ------------------------------------------------------------------------------- Ti ringrazio, a buon rendere! _______________________________________________ [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. 666 iscritti al 22.7.2013 |
|
|
In reply to this post by GEOgrafica
Il giorno Thu, 23 Jan 2014 10:10:13 +0100
GEOgrafica <[hidden email]> ha scritto: ciao Marco, > Il giorno 22/gen/2014, alle ore 20:04, giulianc51 > <[hidden email]> ha scritto: > > > > però mi permetto anche di pensare che il vettoriale è "logicamente" > > superiore (ovviamente in generale, perchè se è derivato da > > raster....); > Ma perchè questa convinzione, da dove viene? oops, non volevo scatenare un flame "vettoriale vs raster" :-( quindi mi scuso se ho dato questa impressione; la frase sopra, che ho effettivamente scritto, era alla fine di una giornata di lavoro: devo probabilmente smettere di inviare in lista alla sera :-) peraltro condivido quanto da te detto a proposito della risoluzione che si adotta; detto questo però...... vedo diversi però, ad es. 1) la risoluzione di cui parli non è una quantità neutrale: sui raster ha un grosso costo nella dimensione (magari compensato dalla semplicità algoritmica), nel vettoriale nessun costo; 2) il raster ha le caratteristiche del discreto, il vettoriale la potenza del continuo; se posso azzardare un paragone: non tutte le equazioni diofantine hanno soluzione; nel campo complesso (un gradino più in là del campo reale) ogni equazione ha soluzione; temo però di uscire dal seminato e non tutti potrebbero essere interessati a questo approccio; io ovviamente sì e sarei ben contento di continuarlo quì o da un'altra parte: imparare è una delle attività più piacevoli della vecchiaia :-) > Ciao! > Marco Gualdrini > GEOgrafica - Faenza grazie, ciao, giuliano melegnano, milano PS: per la birra e matita che citi in un altro post, ben volentieri; purtroppo c'è qualche centinaio di km di distanza (raster o vettoriali che siano :-) ma alla prima occasione ..... _______________________________________________ [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. 666 iscritti al 22.7.2013 |
|
|
In reply to this post by antoniovinci
Al momento non abbiamo realizzato alcun rilievo. In un progetto di un po' di anni fa avevamo georeferenziato solo i due punti di imbocco della grotta, usando una stazione totale e partendo dal catasto fabbricati georeferenziati, ci eravamo portati in giro per la casa i punti fino al piano in cui si accedeva alla grotta. Poi i rilievi fatti dentro alla grotta sono stati rototraslati con gvSIG facendo combaciare i punti di ingresso alla grotta georeferenziati con i punti della grotta digitalizzata con un cad. Questo era il risultato del posizionamento: https://qgiscloud.com/pyarchinit/pyarchinit_landscape Zoomate su Saludecio per vedere le grotte. Non ha un wms sotto perchè Qgiscloud non supportava i WMS quando abbiamo fatto la prova.
Se guardate la grotta numero 1, la più a Nord, lì per esempio avevamo 17 punti per la base della grotta e 17 punti per i soffitti, perchè la grotta è regolare. Mi chiedo se da così pochi punti è possibile ricavare qualcosa.
Ciao Luca 2014/1/23 antoniovinci <[hidden email]> Caro Mando, se possibile, sarebbe interessante sapere come hai _______________________________________________ [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. 666 iscritti al 22.7.2013 |
|
|
In reply to this post by antoniovinci
2014/1/23 antoniovinci <[hidden email]> / Per fare questo, ovvero calcolare lo spessore stratigrafico (archeologico) tra due epoche abbiamo fatto il dem dell'epoca contemporanea, il dem dell'epoca romana, e dal calcolatore raster di Qgis abbiamo sottratto dal primo dem le quote del secondo, ricavando un dem con i dati di spessore.
Poi con il plugin Profile abbiamo realizzate le sezioni generali dell astratigrafia archeologica a livello cittadino.
_______________________________________________ [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. 666 iscritti al 22.7.2013 |
|
In reply to this post by mando
Molto interessante, grazie Mando!
Tirare fuori "qualcosa" da quei 17 punti mi pare francamente un esercizio inutile: ha senso crearsi una mesh sensata partendo da 17...mila punti, ovvero se hai una cosiddetta 'point cloud'. In ogni caso, se incolli qua il listato XYZ, vediamo come sono disposti nello spazio... |
|
|
In reply to this post by Giuliano Curti
Mi permetto di intervenire in questa intereressante cConversazione.Il vettoriale è discreto come i raster. Almeno nelle forme usate. Perché esprima una vera continuità dovrebbe essere espresso da una formula e non da una sequenza di punti . Il 23/gen/2014 12:41 "giulianc51" <[hidden email]> ha scritto:
Il giorno Thu, 23 Jan 2014 10:10:13 +0100 _______________________________________________ [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. 666 iscritti al 22.7.2013 |
|
|
Il giorno Thu, 23 Jan 2014 18:32:06 +0100
Andrea Peri <[hidden email]> ha scritto: ciao Andrea; > Mi permetto di intervenire in questa intereressante cConversazione.Il > vettoriale è discreto come i raster. Almeno nelle forme usate. Perché > esprima una vera continuità dovrebbe essere espresso da una formula e > non da una sequenza di punti . temo di essere diventato un sofista, perchè la tua tesi mi sembra condivisibile o rigettabile a seconda del punto di vista :-) prima di buttarmi a capofitto in una discussione che interessa molto anche a me, posso chiederti di precisare meglio cosa intendi quando dici "Il vettoriale è discreto come i raster", in particolare per l'avverbio "come" ? grazie, ciao, giuliano _______________________________________________ [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. 666 iscritti al 22.7.2013 |
|
|
>> Il vettoriale è discreto come i raster.
>> Perché >> esprima una vera continuità dovrebbe essere espresso da una formula e >> non da una sequenza di punti . Qui si entrerebbe nello spinoso problema della "teoria delle misure" e tutto diventerebbe opinabile. Comunque, fissiamo alcuni "punti" :) 1) DTM, DEM, o DSM sono dei "grid", ovvero una griglia "finita" di altezze, e le coordinate XY sono "implicite", nel senso che non sono dichiarate singolarmente, ma calcolate per iterazione da un programma, che usa parametri dichiarati, quali: punto di origine, numero punti in X, numero punti in Y, distanza DeltaX, distanza DeltaY. 2) Un altro modo di definire il grid DTM è quello di usare un file GeoTIFF, dove in ogni "pixel" viene usato, invece del colore, un codice da leggersi come altezza. 3) I grid DTM/DSM/DEM sono "discreti" nel senso che hanno una risoluzione "finita", e quindi "scalettano" un edificio (nel caso del DSM) o il bordo di una strada (nel caso di un DEM) o la cresta netta di una scogliera (per il DTM). 4) Il "grid", per poter ridurre il difetto della "scalettatura" deve avere una risoluzione elevata, e quindi anche una grandezza elevata. 5) Il "grid" NON PUO' DESCRIVERE CONTROPENDENZE E GROTTE. Punto. 7) (non mi piace il numero sei :) Tutto quello che non fa il "grid", lo fa il TIN. Punto. Con il TIN possono essere descritti oggetti (e anche territori) di tipo "sculturato". Quindi, grotte, scogliere, bordi precisi di tetti, oggetti fotogrammetrici eccetera. E a questo punto scusate lo sfogo, da tecnico del settore: "Finiamola di rilasciare dati provenienti da rilevamenti lidar (o da SfM) utilizzando il grid !" Si perde tutto il dettaglio. Per quanto grossi e ad alta risoluzione si vogliano fornire i grid, praticamente si fornisce "acqua calda". Aspetto repliche :) Roberto Di conseguenza, tutte le schede grafiche supportano ora in maniera egregia il TIN, "progressivo", nel senso che carica i punti, visualizzando gli oggetti in maniera "semplificata" e poi, "con comodo" :) , aggiunge i dettagli, usando anche la distanza di visualizzazione, se occorre. _______________________________________________ [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. 666 iscritti al 22.7.2013 |
|
|
Roby,
non sono d'accordo sul punto 5... Tu puoi immaginare una grotta come il "negativo" o lo "stampo" di un terreno, quindi perfettamente approssimabile in 3D con un Dem raster. L'automobile che ho postato sopra è esempio emblematico di quanto affermo: puoi pensare a quella mesh come "contenitore" dell'abitacolo, oppure come "separatore" del volume dall'ambiente esterno... |
|
|
Il giorno 24/gen/2014, alle ore 10:40, antoniovinci <[hidden email]> ha scritto:
> Roby, > non sono d'accordo sul punto 5... > > Tu puoi immaginare una grotta come il "negativo" o lo "stampo" di un > terreno, quindi perfettamente approssimabile in 3D con un Dem raster. Peccato che una grotta abbia un "tetto" che sta sopra il "pavimento", e che sia piena di aggetti, ovvero di punti con geometria sporgente sopra una parte sottostante. Poiche' il DEM raster prevede una e una sola Z per ogni coppia di punti X e Y, è impossibile usarlo per modellizzare una superficie con aggetti. L'esempio della grotta e' proprio il classico caso dove un DEM raster approssima in modo tutt'altro che perfetto la geometria in considerazione... > L'automobile che ho postato sopra è esempio emblematico di quanto affermo: e infatti l'automobile che hai postato e' approssimata abbastanza bene nella parte superiore, mentre per tutti gli aggetti (dai paraurti in giu') la geometria viene elisa. ciao! Marco Marco Gualdrini GEOgrafica - Faenza ------------------------------------------------------------------------------- GEOgrafica - GIS, cartografia digitale e simulazioni territoriali virtuali www.geografica.org Virtual Terrain Project / GeoView examples: http://youtu.be/qEeGjNvwl4Y http://youtu.be/9UPfufPLQUw http://youtu.be/gv8HgX9TZfs ------------------------------------------------------------------------------- _______________________________________________ [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. 666 iscritti al 22.7.2013 |
|
|
Mah, non credo che lo scopo di Mando sia "ricostruire" stalattiti e stalagmiti (cui prodest?) bensì solo vettorizzare la grotta come mera volumetria pieno/vuoto.
Quanto al Maggiolino, hai perfettamente ragione sul discorso dell'unicità delle Z, ed è il motivo per cui le parti verticali "piovano" parallele alla direzione del filo a piombo... |
|
|
In reply to this post by geodrinx
Il giorno 24/gen/2014, alle ore 07:43, Geodrinx <[hidden email]> ha scritto:
> > > Comunque, fissiamo alcuni "punti" :) concordo su quasi tutto, in particolare sul punto 5). Pero' aggiungo: > > 1) DTM, DEM, o DSM sono dei "grid", ovvero una griglia "finita" di altezze, e le coordinate XY sono "implicite", nel senso che non sono dichiarate singolarmente, ma calcolate per iterazione da un programma, che usa parametri dichiarati, quali: punto di origine, numero punti in X, numero punti in Y, distanza DeltaX, distanza DeltaY. Non solo: un DEM puo' essere anche descritto da una matrice di punti (descritta da file di testo .xyz) costituito da terne di punti X, Y e Z, dove le X e Y incrementano in maniera costante riga per riga. Da non confondersi con una matrice di punti irregolare. > > 7) (non mi piace il numero sei :) > Tutto quello che non fa il "grid", lo fa il TIN. Punto. > Con il TIN possono essere descritti oggetti (e anche territori) di tipo "sculturato". Quindi, grotte, scogliere, bordi precisi di tetti, oggetti fotogrammetrici eccetera. Qui rompo le scatole io, ribadendo che i cosiddetti "bordi precisi" del TIN non sono in realtà precisi, ma sono solo funzione del passo con cui sono stati campionati i vertici dei triangoli che lo costituiscono. Visto che all'atto pratico è impossibile battere punti e creare triangoli "in continuo", si genera sempre una maglia, o mesh che dir si voglia, irregolare questa volta, quindi "potenzialmente" in grado di descrivere meglio le features (purchè si battano per bene le breaklines, e purchè questo sia davvero possibile...), ma all'atto pratico la mesh vettoriale generata e' sempre DISCRETA, come giustamente ha ribadito Andrea Peri. Sempre concretamente parlando, una nuvola di punti generata da un laser scanner all'interno della grotta campiona punti con un passo (espresso in frazioni di grado) attorno alla base rotante. Il modello generato non e' espresso da un'equazione continua, ma dalle terne di coordinate che identificano i vertici dei punti campionati, che NON E' ASSOLUTAMENTE DETTO che abbiano "beccato" le linee di discontinuita' che caratterizzano con precisione assoluta un cambio di geometria, e quindi una maggior precisione rispetto ad una griglia di tipo raster (o voxel) ad alta risoluzione. E siccome queste nuvole di punti sono praticamente ingestibili a livello software, si applicano praticamente sempre dei filtri e delle tecniche di "thinnaggio", tali per cui l'originaria alta risoluzione del dato viene sostituita da triangoli piu' o meno grossi, con vertici "decisi" in postproduzione, e con il rischio (piu' o meno concreto a seconda delle procedure utilizzate e dalla bravura dell'operatore) di "perdersi" delle strutture o breaklines importanti. Sto ovviamente pensando a casi concreti su cui ho esperienze, ad esempio rilievi laser scanner di pareti rocciose con ricerca di microstrutture, o rilievi in grotte carsiche. > > E a questo punto scusate lo sfogo, da tecnico del settore: > "Finiamola di rilasciare dati provenienti da rilevamenti lidar (o da SfM) utilizzando il grid !" Se il LIDAR e' di un terreno ed e' stato fatto da elicottero o aereo, in caso di aggetti le parti sovrastanti hanno comunque coperto le parti sottostanti per effetto della prospettiva, quindi in questo specifico caso e' piu' che adeguato usare un grid per un rilievo LIDAR, se questo e' stato fatto a quota costante. Ciao! Marco Marco Gualdrini GEOgrafica - Faenza ------------------------------------------------------------------------------- GEOgrafica - GIS, cartografia digitale e simulazioni territoriali virtuali www.geografica.org Virtual Terrain Project / GeoView examples: http://youtu.be/qEeGjNvwl4Y http://youtu.be/9UPfufPLQUw http://youtu.be/gv8HgX9TZfs ------------------------------------------------------------------------------- _______________________________________________ [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. 666 iscritti al 22.7.2013 |
|
|
In reply to this post by antoniovinci
Il giorno 24/gen/2014, alle ore 11:40, antoniovinci <[hidden email]> ha scritto:
> Mah, non credo che lo scopo di Mando sia "ricostruire" stalattiti e > stalagmiti (/cui prodest?/) bensì solo vettorizzare la grotta come mera > volumetria pieno/vuoto. cui prodest? e lo decidi tu? :D chi si occupa di rilievi in ambito archeologico o geologico/strutturale prima o poi si trova di fronte al problema di restituire uno o più aggetti (in realtà, se ne trovano a bizzeffe!). Ad esempio, una nicchia in una parete, una cavità.... Ecco che il DEM raster non va piu' bene. Ed ecco che l'unico modo e' usare una mesh vettoriale (restituita con laser scanner o con fotogrammetria terrestre) o un insieme di voxel. > > Quanto al Maggiolino, hai perfettamente ragione sul discorso dell'unicità > delle Z, ed è il motivo per cui le parti verticali "piovano" parallele alla > direzione del filo a piombo... Ed e' quello che dice Roberto al punto 5 del suo post. Un grid non puo' gestire gli aggetti, una mesh si. Punto. :D Ciao! Marco Marco Gualdrini GEOgrafica - Faenza ------------------------------------------------------------------------------- GEOgrafica - GIS, cartografia digitale e simulazioni territoriali virtuali www.geografica.org Virtual Terrain Project / GeoView examples: http://youtu.be/qEeGjNvwl4Y http://youtu.be/9UPfufPLQUw http://youtu.be/gv8HgX9TZfs ------------------------------------------------------------------------------- _______________________________________________ [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. 666 iscritti al 22.7.2013 |
|
|
In reply to this post by GEOgrafica
Ciao Marco,
> Con il TIN possono essere descritti oggetti (e anche territori) di tipo "sculturato". Quindi, grotte, scogliere, bordi precisi di tetti, oggetti fotogrammetrici eccetera.
Ripeto: "Teoria delle Misure". Ma esuliamo da quello di cui ci vogliamo occupare. Comunque, il perfetto non esiste, e ogni punto misurato, una volta ri-misurato assume altre coordinate. OK. Ma questo è vero sempre. Per i TIN e per il vettoriale fotogrammetrico più tradizionale, per il catasto, eccetera. Direbbe il mio professore di Topografia: "Non mi divaghi..." :) Quindi, tornando invece alla tipologia di dati TIN, supponendo di aver preso una serie di punti da un rilevamento ( e NON da un ricampionamento !!! ), tenuto conto della perfettibilità di qualunque rilievo, della precisione degli strumenti, eccetera eccetera, e di quello che vuoi per rendere quel punto il più possibile unico e irripetibile... ... orbene, quella Nuvola di Punti ( "Point Cloud" ) derivata da un rilievo LiDAR, SfM, oppure anche da "stazione totale" , quella Nuvola di Punti, dicevo, viene ricostruita come superficie tramite diverse tecniche, che costruiscono il "Grafo dei Triangoli", ovvero il TIN SCULTURATO degli oggetti contenuti nella nuvola di punti. Questo è un campo affascinante della "Teoria dei Modelli" e della "Cluster Analisys". Tramite queste tecniche si riesce a tirare fuori da un "ammasso informe di punti" uno o più oggetti, fatti da tanti triangolini minuscoli, che, nel caso del LiDAR, o meglio ancora dalla SfM, possono essere colorati dalle immagini che hanno direttamente generato i punti ( per la SfM ) oppure dalle immagini "accoppiate" ai punti ( come nel caso del LiDAR ). Tu dici bene: il LiDAR, oppure anche il Laser terrestre sembrano un "cieco che tocca un modello", e il difetto che si trova è che "di punti ce ne sono tanti, anche troppi, ma mancano quelli utili" :) Un po' meglio si va con la "Structure from Motion", anche se... ha anch'essa i suoi difetti ( come tutti i metodi di misura ), ma almeno i punti che si ottengono sono direttamente i punti visibili dalle immagini ( e quindi, capita più spesso che siano i contorni apparenti degli oggetti ). Ma comunque, ripeto... è roba da "Teoria delle Misure"... :) Tu dici "E siccome queste nuvole di punti sono praticamente ingestibili a livello software." Appunto di questo stiamo parlando: porre le basi per fare in modo che il software si occupi di questo. :) In conclusione, sto parlando di TIN "sculturati", e non di TIN salvati a partire da un DTM, il che significherebbe solo... una complicazione inutile, che non aggiunge nulla ai dati di partenza, che non contengono contemporaneamente, come tu stesso dici, il pavimento ed il soffitto :) E io aggiungerei: il TIN contiene anche le pareti verticali, che NON CI SONO nel DTM. Riassumendo: parliamo di TIN da SfM. Questo soltanto mi preme implementare in questo momento.
Ok, questa me la invio anche da solo e la porto nel mio prossimo convegno ;) Ciao e grazie Roberto _______________________________________________ [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. 666 iscritti al 22.7.2013 |
|
|
In reply to this post by antoniovinci
Il giorno Fri, 24 Jan 2014 01:40:01 -0800 (PST)
antoniovinci <[hidden email]> ha scritto: ciao Antonio, > Roby, > non sono d'accordo sul punto 5... > > Tu puoi immaginare una grotta come il "negativo" o lo "stampo" di un > terreno, quindi perfettamente approssimabile in 3D con un Dem raster. sono stato battuto sul tempo, ma anch'io credo abbia ragione Roberto, in un pixel puoi mettere tutti i byte che vuoi ma rappresenti sempre e soltanto o il sotto o il sopra :-) (topologo cercasi :-) certo, potresti sempre usare meta bytes per il sotto e metà per il sopra, ma..... ciao, giuliano _______________________________________________ [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. 666 iscritti al 22.7.2013 |
|
|
In reply to this post by GEOgrafica
Il giorno Fri, 24 Jan 2014 11:42:53 +0100
GEOgrafica <[hidden email]> ha scritto: ciao Marco, > Il giorno 24/gen/2014, alle ore 07:43, Geodrinx <[hidden email]> > ha scritto: > > ..... > > 7) (non mi piace il numero sei :) > > Tutto quello che non fa il "grid", lo fa il TIN. Punto. > > Con il TIN possono essere descritti oggetti (e anche territori) di > > tipo "sculturato". Quindi, grotte, scogliere, bordi precisi di > > tetti, oggetti fotogrammetrici eccetera. > Qui rompo le scatole io, ribadendo che i cosiddetti "bordi precisi" > del TIN non sono in realtà precisi, ma sono solo funzione del passo > con cui sono stati campionati i vertici dei triangoli che lo > costituiscono. ...... quì però temo ci sia un equivoco semantico che provo a spiegare :-) se un fisico mi spiega che il 1.5 kg di frutta che ho in mano non è in realtà tale, ma potrebbe essere 1.501, 1.502, 1.499, 1.498 kg perchè dipende dalle condizioni ambientali, dalla sensibilità della pesa e probabilmente da migliaia di altre cose, okay; se l'informatico aggiungesse che no, per la rappresentazione numerica nei circuiti digitali, il peso può essere o 1.490 o 1.495 o 1.500 o 1.505, ecc kg, capisco ancora (è a questo che ti riferivi Anrea nel tuo post?); ma se il fruttivendolo mi fa pagare 2 kg perchè la risoluzione della sua pesa è 1kg, beh, capisco meno :-) di cosa stiamo parlando: del fisico, dell'informatico o del fruttivendolo furbo? (non me ne vogliano i fruttivendoli, ci sono anche gli architetti furbi :-( > Ciao! > Marco ciao :-) giuliano _______________________________________________ [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. 666 iscritti al 22.7.2013 |
|
|
In reply to this post by Giuliano Curti
Ciao Giulia',
resto sulla posizione e rilancio. Per me ingenuo gissaro, una grotta non è un "insieme di aggetti" come stanno dicendo gli ottimi Roberto&Marco, bensì la somma di 2 Dem: un soffitto concavo ed un pavimento convesso, punto. Sarà una semplificazione, ma il modello digitale di quella grotta lo immagino così, senza pendagli rocciosi o vibratori litoidei che fuoriescono dal terreno... |
|
|
Qualcuno ha mai provato cloudcompare in grado di georeferenziare mesh e un add on di grass 7 che parte gestisca mesh o ply georeferenziate? Il giorno 24/gen/2014 13:21, "antoniovinci" <[hidden email]> ha scritto:
Ciao Giulia', _______________________________________________ [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. 666 iscritti al 22.7.2013 |
|
|
Ciao Luca,
Sì, io uso CloudCompare per disegnare linee a partire da rilievi SfM, ed anche per estrarre i punti di controllo per georeferenziare i modelli 3D e le relative ortofoto. Ha colto nel segno :)
Invece, non riesco ancora a provare il loader di PLY di Grass 7, perchè QGis ancora non supporta questa versione di Grass. Almeno credo. Domanda: quando, QGis supporterà Grass 7 ? Grazie Roberto _______________________________________________ [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. 666 iscritti al 22.7.2013 |
«
Return to Gfoss -- Geographic Free and Open Source Software - Italian mailing list
|
1 view|%1 views
| Free forum by Nabble | Edit this page |