Gis e Cad3D
Locked
12345
12345
 
|
Il giorno Sat, 25 Jan 2014 11:02:31 +0100
aperi2007 <[hidden email]> ha scritto: ciao Andrea, > .... una regola di univocita' tra cio' che si vede sullo > schermo e il mouse , che è lo strumento con cui si opera. > > Il che vuole dire che a una coppia di coordinate in pixel (o in > terreno ) dello schermo, > deve esempre corrispondere un risultato univoco. uhmmm.. la vista assonometrica e/o prospettica non sono biunivoche in quanto non iniettive: due punti diversi possono avere la stessa immagine e quindi il mouse avrà difficoltà ad identificare uno o l'altro dei punti, pur tuttavia sono regolarmente impiegate per l'interazione con l'utente in diversi ambiti informatici; > Andrea. 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 Ruggero Bonisolli
Il giorno Fri, 24 Jan 2014 15:17:04 +0100
Ruggero Bonisolli <[hidden email]> ha scritto: > ..... > Se a qualcuno interessa potremmo anche pensare di organizzare un > corso qui al Politecnico Milano. OT: scusa, è molto tempo che non passo di lì: p.zza Leonardo? e il Centro di Ateneo per la Grafica esiste ancora? > Comunque grande, complimenti, anche per il maggiolino, dico. > R 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 mauro alberti
Strano, e' un ridicolo file zippato da 300 KB, gentilmente riprova da qui: http://en.file-upload.net/download-8551212/elba-antielba.zip.html |
|
|
In reply to this post by Giuliano Curti
Rispondo tra i punti.
Il giorno 25 gennaio 2014 14:39, giulianc51 <[hidden email]> ha scritto: Il giorno Sat, 25 Jan 2014 10:46:44 +0100 Sbaglio mio. Purtroppo sono arrugginitoo su queste cose. Non dovevo citare funzioni biunivoche, ma bensi' funzione univoche. Non serve garantire l'esistenza dell'inversa. La funzione quadratica per il resto va bene come citazione.
(teorema di shannon)
STai immaginando un raster a valori interi ? Non è di questo che io parlavo. Un raster puo' ospitare anche valori FloatingPoint. l'integrale (o somma) di tutto sarà 0; se l'intensità fosse 0.51, il Il mio ragionamento è sul numero di campioni che servono per rappresentare "esattamente" una quantita' continua. Il teorema di shannon mi dice che il campionamento deve avvenire a frequenza doppia della frequenza dell'entita' analogica che voglio campionare. Se la tua entita' da campionare è costante, la sua frequenza è zero. Per cui ti basta 1 solo campione per rappresentarla. Quindi ti basta un solo valore nel tuo vettore per esprimere su qualsiasi punto il tuo fenomeno costante. Analogamente se ragioni in raster ti basta una sola cella di ampiezza pari all'intero zona di analisi che esprima tale valore. E' sempre 1 solo valore. Ma forse non ho capito il tuo esempio ? il "mio" vettore mi darà 4.9 o 5.1; -- ----------------- 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. 666 iscritti al 22.7.2013 |
|
|
Il giorno Sat, 25 Jan 2014 15:32:25 +0100
Andrea Peri <[hidden email]> ha scritto: > Rispondo tra i punti. invece io, scusa, riparto daccapo; sempre che sia di comune interesse (per me lo è), senza voler convincere nessuno (ed io non lo voglio fare) e che gli altri abbiano la pazienza di sopportare; mi metterei nell'esempio da cui siamo partiti: uno strumento raster ed uno vettoriale per esprimere l'elevazione di un terreno; poniamo che il raster abbia una maglia 1x1m tanto per fissare le idee; mi sembra di aver capito dalle cose che diceva marco (ma correggimi se ho capito male) che normalmente si usa 1byte = 256 valori; il pixel 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 giorno Sat, 25 Jan 2014 15:55:17 +0100
giulianc51 <[hidden email]> ha scritto: chiedo scusa, mail finita in rete anzichè nel cestino; la stavo riscrivendo ma ho pigiato il tasto sbagliato: vuole dire che anche il sabato pomeriggio dovrei evitare di scrivere :-) :-) chiedo venia, a più tardi per una mail più "ragionata" (almeno spero :-) > Il giorno Sat, 25 Jan 2014 15:32:25 +0100 > Andrea Peri <[hidden email]> ha scritto: > > > Rispondo tra i punti. > > invece io, scusa, riparto daccapo; sempre che sia di comune interesse > (per me lo è), senza voler convincere nessuno (ed io non lo voglio > fare) e che gli altri abbiano la pazienza di sopportare; > > mi metterei nell'esempio da cui siamo partiti: uno strumento raster ed > uno vettoriale per esprimere l'elevazione di un terreno; poniamo che > il raster abbia una maglia 1x1m tanto per fissare le idee; > > mi sembra di aver capito dalle cose che diceva marco (ma correggimi se > ho capito male) che normalmente si usa 1byte = 256 valori; > > > il pixel > > > > 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 |
|
|
In reply to this post by Andrea Peri
Il giorno Sat, 25 Jan 2014 15:32:25 +0100
Andrea Peri <[hidden email]> ha scritto: > Rispondo tra i punti. eccomi :-) spiegami bene (per favore e se ne hai voglia) il tuo punto di vista su questo: > .... > STai immaginando un raster a valori interi ? > Non è di questo che io parlavo. Un raster puo' ospitare anche valori > FloatingPoint. effettivamente da quello che diceva Marco avevo capito quello e a quello pensavo: profondità 1byte = 256 valori interi; con un pizzico di sofisticazione in più questi possono essere indici ad una look at table che può contenere anche valori in virgola mobile; ma voglio seguire il tuo ragionamento: ammesso che il raster sia a "valori razionali", quanti valori diversi sarà in grado di ospitare? 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 |
|
|
In reply to this post by Giuliano Curti
Ottimo, Giuliano
> se i pitagorici avessero scoperto 2000 anni fa che la diagonale del > quadrato poteva essere "discretzzata" in 1.41 o 1.42 (o pi.greco in > 3.14 o 3.15) non sarebbero scomparsi come neve al sole e sarebbero > ancora qui pronti per qualche libro di Eco :-) +1 anzi: 3.141592653589793.....etc etc ;) Roberto "Il mondo è discretamente continuo, oppure é continuamente discreto?" Un dilemma tendente a infinito...;) _______________________________________________ [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
> ammesso che il raster sia a > "valori razionali", quanti valori diversi sarà in grado di ospitare? Il DTM che attualmente mi è stato fornito è un GeoTIFF che ha una profondità colore di 24 bit, e usa tutte e tre le componenti ( R, G e B ) in maniera indipendente, permettendo così la mappatura delle altezze diverse da -16 milioni e rotti a +16 milioni e rotti. Possono bastare ? :) Ciao Roberto > > > 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 [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 Sat, 25 Jan 2014 17:14:45 +0100
Geodrinx <[hidden email]> ha scritto: > > > ammesso che il raster sia a > > "valori razionali", quanti valori diversi sarà in grado di ospitare? > > Il DTM che attualmente mi è stato fornito è un GeoTIFF che ha una > profondità colore di 24 bit, e usa tutte e tre le componenti ( R, G e > B ) in maniera indipendente, permettendo così la mappatura delle > altezze diverse da -16 milioni e rotti a +16 milioni e rotti. > > Possono bastare ? > > :) sì, penso di sì -) però attenzione, non dimentichiamo la risoluzione nel piano :-) :-) :-) > Ciao > Roberto 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 geodrinx
On Sat, 25 Jan 2014 17:14:45 +0100, Geodrinx wrote:
>> ammesso che il raster sia a >> "valori razionali", quanti valori diversi sarà in grado di ospitare? > > Il DTM che attualmente mi è stato fornito è un GeoTIFF che ha una > profondità colore di 24 bit, e usa tutte e tre le componenti ( R, G e > B ) in maniera indipendente, permettendo così la mappatura delle > altezze diverse da -16 milioni e rotti a +16 milioni e rotti. > > Possono bastare ? > > :) > On Sat, 25 Jan 2014 17:14:45 +0100, Geodrinx wrote: >> ammesso che il raster sia a >> "valori razionali", quanti valori diversi sarà in grado di ospitare? > > Il DTM che attualmente mi è stato fornito è un GeoTIFF che ha una > profondità colore di 24 bit, e usa tutte e tre le componenti ( R, G e > B ) in maniera indipendente, permettendo così la mappatura delle > altezze diverse da -16 milioni e rotti a +16 milioni e rotti. > formato decisamente bizzarro :-P perche' non hanno usato le impostazioni canoniche del TIFF corrispondenti ad un pixel di tipo floating-point (single oppure double precision) ? c'e' qualche motivo razionale ? oppure e' semplicemente per risparmiare 1 byte ogni 4 (24 bit anziche' 32 bit) andandosi ad inventare una codifica assolutamente fuori standard ? BTW la rappresentazione standard "fp double" si porta dietro 64bit di precisione (cioe' e' incommensurabilmente piu' precisa). per capirsi meglio: la rappresentazione "canonica" che mi attenderei in un DEM "estremamente preciso" sarebbe di questo tipo: TIFFSetField (tiff, TIFFTAG_SAMPLEFORMAT, SAMPLEFORMAT_IEEEFP); TIFFSetField (tiff, TIFFTAG_SAMPLESPERPIXEL, 1); TIFFSetField (tiff, TIFFTAG_PHOTOMETRIC, PHOTOMETRIC_MINISBLACK); TIFFSetField (tiff, TIFFTAG_BITSPERSAMPLE, 32); /* single */ TIFFSetField (tiff, TIFFTAG_BITSPERSAMPLE, 64); /* double */ da quel che ci riferisci invece sembrerebbe che i tuoi samples usino qualcosa di questo tenore: TIFFSetField (tiff, TIFFTAG_SAMPLEFORMAT, SAMPLEFORMAT_UINT); TIFFSetField (tiff, TIFFTAG_SAMPLESPERPIXEL, 3); TIFFSetField (tiff, TIFFTAG_PHOTOMETRIC, PHOTOMETRIC_RGB); TIFFSetField (tiff, TIFFTAG_BITSPERSAMPLE, 8); ma nulla fa sospettare che un (geo)TIFF dichiarato in questo modo contenga misure di elevazione; al contrario, tutto farebbe capire che si tratta piuttosto di un banale RGB. ed in ogni caso poi come avverrebbe l'interpretazione dei valori di altezza ? ... non mi e' del tutto chiaro, ed a lume di naso pare che serva adottare necessariamente qualche convenzione arbitraria assolutamente fuori standard. 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. 666 iscritti al 22.7.2013 |
|
|
In reply to this post by antoniovinci
2014-01-25 antoniovinci <[hidden email]> / da questi dati ho creato il profilo caricato in:
non sono riuscito a duplicare l'errore di cui parlavi. ciao m _______________________________________________ [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
Il giorno 25/gen/2014, alle ore 15:55, giulianc51 <[hidden email]> ha scritto:
> > mi sembra di aver capito dalle cose che diceva marco (ma correggimi se > ho capito male) che normalmente si usa 1byte = 256 valori; Hai capito male. Io facevo riferimento al metodo (pedestre) che voleva usare Roberto e Antonio per lavorare con un WMS per esprimere un DEM. In quel caso non hai altro modo se non quello di suddividere il range in 256 valori, visto che si lavora su un singolo canale a 8 bit. Pero' poi ho sempre aggiunto che la cosa che ha senso non e' quel metodo pedestre, ma quello di lavorare su un raster "vero", ovvero non una IMMAGINE con una palette a 8 bit. In quel caso (WCS) ogni cella del raster puo' assumere qualunque valore, anche in virgola mobile. E' la stessa cosa di un DEM in formato GeoTIFF, dove ogni quota puo' essere espressa in valore assoluto. 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 Giuliano Curti
Si parla di dati raster. Un dato raster puo' essere archiviato in un formato capace di ospitarlo. Ad esempio un ascii-grid. Ma anche in TIFF puo' ospitare un raster. Un GIF (per esemplificare un formato alternativo) potrebbe ospitarlo se il dato raster è basato su una maglia regolare e ha valori di quota (se tale è il valore che esprime per ogni cella) interi da 0 a 255. Un TIFF , invece, puo' ospitare anche dati in FP64 (floating point). http://en.wikipedia.org/wiki/Tagged_Image_File_Format Ciao.>The inclusion of the SampleFormat tag in TIFF 6.0 allows TIFF files to handle advanced pixel data types, including integer images with more >than 8 bits per channel and floating point images. Il giorno 25 gennaio 2014 16:10, giulianc51 <[hidden email]> ha scritto: Il giorno Sat, 25 Jan 2014 15:32:25 +0100 -- ----------------- 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. 666 iscritti al 22.7.2013 |
|
|
In reply to this post by a.furieri
Il giorno 25/gen/2014, alle ore 17:40, [hidden email] ha scritto:
>> > > On Sat, 25 Jan 2014 17:14:45 +0100, Geodrinx wrote: >>> ammesso che il raster sia a >>> "valori razionali", quanti valori diversi sarà in grado di ospitare? >> >> Il DTM che attualmente mi è stato fornito è un GeoTIFF che ha una >> profondità colore di 24 bit, e usa tutte e tre le componenti ( R, G e >> B ) in maniera indipendente, permettendo così la mappatura delle >> altezze diverse da -16 milioni e rotti a +16 milioni e rotti. >> > > formato decisamente bizzarro :-P > > perche' non hanno usato le impostazioni canoniche del TIFF > corrispondenti ad un pixel di tipo floating-point (single > oppure double precision) ? Infatti secondo me Roberto si sbaglia. In questa discussione e' venuto fuori un gran casotto! Si e' partiti dal voler utilizzare in modo improprio un WMS per rappresentare un DEM, arrampicandosi sugli specchi per gestire la palette a 24 bit come valori di elevation. Io ho cercato di far notare come questo modo era alquanto bizzarro e improprio, e che l'unico modo "logico", se proprio si voleva usare una IMMAGINE e non un RASTER (evidentemente la differenza tra i due oggetti non e' stata colta) era eventualmente di utilizzare una immagine ad una sola banda (quindi, scala di grigio) avendo pero' l'accortezza di lavorare almeno a 16 bit altrimenti i valori rappresentabili sarebbero stati solo 256, mentre con i 16 bit sarebbero stati almeno 65K9. Ho poi subito aggiunto che l'unico sistema veramente efficente per servire dati raster in rete era il WCS, dove il valore associato alla singola cella sarebbe stato libero, floating point, quindi non legato ai valori di tre bande - e questo per dissuadere Roberto dal voler usare una sua palette con la quale, attraverso una opportuna look at table, si sarebbero potuti ridefinire i valori delle quote). Da quel punto in poi, abbiamo iniziato ad arrovagliarci su piani paralleli, scrivendo scrivendo (di precisione, di ordini di grandezza di superiorita' del vettoriale rispetto al raster, di caverne fatte solo come palle ma senza sporti nelle parti subverticali) ma senza realmente capire se stavamo parlando delle stesse cose. Da quello che scrive Giuliano mi par di capire che si stiano ancora confondendo i formati raster floating point ( i raster per lo storage di informazioni GIS, non le immagini raster) e, appunto, i vari formati di immagine una banda, 3 bande, 8 bit, 24 bit, 32 bit...... L'intervento di Sandro Furieri spero riporti il discorso nel seminato! 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 mauro alberti
@ Mauro
Splendido, lunedi' provo sul Qgis dell'ufficio. @ Roberto Potresti condividere con noi quel sedicente Dem a 24 bit? Grazie! |
|
|
In reply to this post by GEOgrafica
Il giorno Sat, 25 Jan 2014 18:06:21 +0100
GEOgrafica <[hidden email]> ha scritto: > Il giorno 25/gen/2014, alle ore 17:40, [hidden email] ha scritto: > >> > > > > On Sat, 25 Jan 2014 17:14:45 +0100, Geodrinx wrote: > >>> ciao, Marco e Andrea (anche Sandro ma il tuo intervento era troppo tecnico per la mia attuale competenza sull'argomento), grazie perchè mi avete fatto capire che forse è un problema di linguaggio: se c'è differenza fra IMMAGINE (in senso informatico, non algebrico) e RASTER, che io ovviamente non trovo, vuol dire che le mie fonti in Foley/VanDam e Newman/Sproull sono arrugginite :-) lasciatemele aggiornare e riprenderò l'argomento, siatene certi :-) :-) :-) per adesso zittisco :-) :-) :-) > 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 |
Administrator
|
qui c'è da stampare tutto il thread e rilegarlo in comode dispense...
grazie a tutti: leggo e non è detto che impari :-) s. |
|
|
immagino interessi... fresco fresco ---------- Forwarded message ---------- From: Olivier Dalang <[hidden email]> Date: 26 January 2014 03:08 Subject: [Qgis-developer] Cad-Input for QGIS prototype To: "[hidden email]" <[hidden email]> Cc: Diego Gnesi Bartolani <[hidden email]>, antoniolocandro <[hidden email]>
Dear list, Some times ago, on this list, we discussed[1] about real CAD-like input for QGIS, and since I do myself long for such a feature very much, I'd like to reopen that discussion by proposing a python prototype.
I know there are already a few plugins aiming in that direction (CadTools, ImprovedPolygonCapturing, NumericalInput and a few other). They provide the functionality, but not the ease of use you can find in CAD packages.
One key aspect is that they are all specific tools, and do not work with other tools directly. The prototype is inspired from Archicad's input method which allows to combine numeric input with mouse input in a very efficient and flexible manner, to get the best of both.
It is currently very raw and not well tested at all... It also relies on a lot of dirty hacks, since the python API is not well suited for this type of plugins (have a look at the README on the github page for more details).
DEMO (video) : https://vimeo.com/85052231 GITHUB (readme, download...) : https://github.com/olivierdalang/CadInput
Please, tell me what you think : 1) Concept - Does this kind of input seem interesting to you ? - How does it fit in a GIS-environment ? Since it comes from a CAD environment, maybe it's more suited to designing than digitizing.
2) API/Core modifications (read https://github.com/olivierdalang/CadInput#technical-notes ) - How do you see the suggested improvements ? Are they feasible ?
- Does developing this as a python plugin make sense, or does it have to be in the core from the start ? (I'm not familiar with core developing) 3) Collaboration... - Is anyone of you currently working on the same topic ?
- Would anyone have some time/interest in collaborating on this feature ? 4) Other ideas are welcome ! Thanks for your attention,
Olivier (To those from this discussion I cc'ed, I though you may be interested, I hope you don't mind) 2014-01-26 stefano campus <[hidden email]> qui c'è da stampare tutto il thread e rilegarlo in comode dispense... _______________________________________________ [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
Buongiorno Sto provando le potenzialità del plugin qgis2leaf e lo trovo molto interessante, l'unico problema è che riesc oa visualizzare solamente lo stile di base, cioè il punto pieno, la linea continua e il poligono pieno. E' possibile visualizzare con stili diversi? Tipo le linee tratteggiate, i poligoni solo con il bordo, simboli sui punti.... Grazie a tutti Carlo _______________________________________________ [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+40 iscritti al 5.6.2014 |
«
Return to Gfoss -- Geographic Free and Open Source Software - Italian mailing list
|
1 view|%1 views
| Free forum by Nabble | Edit this page |