Inizio implementazione formato TIN in QGis

[Carlo Cormio]

Si può utilizzare anche v.trimesh, che utilizza sempre triangle per la triangolazione, ma credo che v.triangle sia decisamente migliore.

Era ora!

Grazie mille ad Alexander Muriy!!!!!!!

Ciao,

Carlo

Il 10/05/2012 18:42, Markus Neteler ha scritto:

Ciao,

vi segnalo allora anche un nuovo addon di GRASS:

TIN with breaklines: v.triangle module
http://grass.osgeo.org/wiki/TIN_with_breaklines

ciao
Markus

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

[Markus Neteler]

2012/5/11 Paolo Cavallini <[hidden email]>:
> Il 11/05/2012 13:41, Markus Neteler ha scritto:
>> 2012/5/11 Luca Delucchi <[hidden email]>:
>> ..
>>> non so se mai lo sarà perchè credo che prima dovrebbe diventare un
>>> modulo "ufficiale" di grass
>>
>> ... oppure Sextante supporta GRASS Addons :)
>
> in che modo potrebbe? ci spieghi?

Usando g.extension:
- per Linux-Mac richiede attualmente la presenza di un compilatore
sulla macchina
- per Windows si pesca il binario precompilato (ogni notte) da un
server di GRASS

ciao
Markus
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

[pcav]

Il 11/05/2012 15:34, Markus Neteler ha scritto:
> Usando g.extension:
> - per Linux-Mac richiede attualmente la presenza di un compilatore
> sulla macchina
> - per Windows si pesca il binario precompilato (ogni notte) da un
> server di GRASS

Quindi in pratica:
- aggiungere g.extension ai moduli grass in sextante in qgis
- aggiungere un metodo con cui creare i nuovi files di supporto per i moduli
installati; a quel punto l'esigenza dell'automatizzazione si fa impellente.
Mi preoccupa un po' la presenza di molti pezzi: con tutta questa complessita' in
piu', molte cose si possono rompere.
Per capire: qual e' il vantaggio a tenere gli addons fuori del codice main?
Grazie.
--
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012

[Markus Neteler]

2012/5/11 Paolo Cavallini <[hidden email]>:
..
> Per capire: qual e' il vantaggio a tenere gli addons fuori del codice main?

L'addons è come una incubatrice per codice nuovo.

Qualche modulo resterà per sempre in Addons per motivi vari:
- troppo specialistico (non vogliamo avere un GRASS main
  con 1000 comandi!)
- se ha qualche limite: non stabile, non documentato,
   non portabile ecc.
- ...

Cmq, quando un modulo in Addons è maturato e di interesse
generale viene poi messo nel codice main. E' successo spesso.

ciao
Markus

PS: Prima di buttarsi su g.extension è più importante far funzionare
il "resto"...
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
Non inviate messaggi commerciali.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
584 iscritti al 7.4.2012