[Gfoss] Gfoss Digest, Vol 23, Issue 88

Ciao,

quoto in pieno quanto espresso da Ivan.
grass è la nosrta punta di diamante penso non ci siano dubbi!
(ci sono cose che arc-zozz non farà mai … tipo g.region -a …)

che grass sia difficile…dipende da persona a persona,
quindi a qualcuno farebbe comodo usare qgis come front end…
almeno per ora che wxgrass ancora non è pronta.

penso che il problema non sia insormontabile, senza andare a sbattere su gvsig …

io direi di :

  • fare testing sui moduli q-grass per verificarne la funzionalità , e apportare modifiche la dove necessario (…tipo … mi serve un flag che in grass c’è ma in qgis è nascosto…etc…)
  • vedere cosa manca in qgis, ma che in grass c’è per eventuali aggiunte di moduli
  • identificare tutti i processi e/o comandi che sono non facili da utilizzare, o che richiedono l’utilizzo di moduli esterni (vedi gdal-translate, pstoedit, ppmtompeg, e tanti altri…)
  • ricdercare procedure “di uso comune” che richiedono l’utilizzo di piu comandi in successione , creare script-grass che le automatizzino, e di conseguenza aggiungere il modulo in qgis

scusate se il concetto può sebrare un po contorto,
ma noi gli strumenti li abbiamo, sono potenti quanto basta! … bisogna solo modellarli un pò

p.s.

perche scartare l’idea di integrare R ???

si scelgono le funzioni “spaziali” di base (ecdf plot, barplot(raster su raster - raster su vector), pie, cluster … ) e
si scriptano pure quelle
e l’utente manco se ne accorge che sta usando un altro applicativo
l’installazzione di r non richiede nulla! c’è il binario (o repository) per tutte la platform

Il giorno 24/mag/07, alle ore 10:03, gfoss-request@faunalia.com ha scritto:

ivan marchesini ha scritto:

Ciao a tutti…

con questa storia che Grass ? difficile per? si finisce per non

diffonderlo…

e quello che otteniamo ? che la gente dica:

"si si lo so ? potente ma troppo difficile… quindi non adatto per gli

uffici o i professionisti"…

in realt? grass ? la nostra punta di diamante…

colui che ci risolve spesso un sacco di problemi…

si pu? lavorare per renderlo pi? semplice ma un oggetto potente ? per

sua natura complesso…

voler andare al confronto gvsig - arcgis ? come spararsi nelle “…”

non regge…

io sono per spingere su grass…

? l’unico strumento “completo” di cui disponiamo al momento…

non supportarlo con decisione mi pare miope…

se poi si vuole usare qgis come supporto a grass e gvsig per il layout e

altre poche cosette ben venga… ma sono sempre e comunque per spingere

su grass…

ciao

Su questo sono d’accordo, per? alcune cosine per rendere user-friendly

le operazioni pi? comuni (vedi la trasparenza) tramite qgis andrebbero

proprio aggiunte. Poi ? ovvio che non si pu? rendere semplice quello che

semplice non ?..per? non tutti fanno solo analisi di dati,

qualcuno stampa anche delle banali carte. Sono un utente di grass fino

dalla versione 4 e lo uso tuttora, quindi sono assolutamente dalla tua

parte, ma non si pu? negare che il plugin qgis-grass abbia decisamente

facilitato le cose, vorrei che si continuasse su questa strada!

Il giorno gio, 24/05/2007 alle 09.00 +0200, Patti Giuseppe ha scritto:

Dico la mia anche io. Sul pc ufficio ho installato gvSig, Qgis e Grass,

ma ho provato anche SAGA Gis, UDig ecc. ecc.

E’ vero che gvSig manca di alcuni strumenti, tuttavia per l’utente al

primo impatto che per prima cosa cerca magari di realizzare una mappa

senza dover fare molte analisi gvSig ? immediato e semplice da usare e

include strumenti di digitalizzazione dei vettoriali molto interessanti,

ad es. si pu? fare la digitalizzazione di un nuovo layer usando lo snap

ad un altro layer visualizzato, si possono spostare elementi esistenti

di una quantit? definita in stile cad, per non parlare della possibilit?

di assegnare la trasparenza e il colore ai raster sulla base dei valori

in maniera semplice e veloce.

E’ pur vero che queste cose si possono fare anche con QGis+Grass, ma il

problema rimane sempre quello della semplicit? di fare le cose: se per

avvicinare un utente a QGis e ad es. voglio sovrapporre un raster con

trasparenza sul valore 0 devo speigargli di passare per gdal_translate

oppure importare il raster in grass e usare r.null…questa ? una

funzione base di un gis che manca.

In gvSig si pu? fare semplicemente dalle propriet? del raster, poi ?

vero che sul mio ormai obsoleto Pentium IV quando carico molti dati con

Java diventa un p? lento…

Saluti

Paolo Cavallini ha scritto:

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA1

Io per ora non investo in gvSIG, al di la’ delle questioni funzionali,

perche’ non mi fido di una comunita’ “nata in laboratorio”, costruita

dalle istituzioni. Temo che una volta finiti i finanziamenti la cosa

possa morire, o comunque arenarsi. Tecnicamente, il fatto che viva un

po’ in isolamento rispetto agli altri tools liberi anche questo non me

lo fa piacere granche’.

Naturalmente sono scelte mie, ognuno e’ libero. Se poi le cose cambiano,

si fa presto a mutare rotta.

Per l’ECDL-GIS, e’ auspicabile fare anche un altro set di domande per

gvSIG, in modo da offrire la scelta fra due SW proprietari (ESRI e

Intergraph) e due liberi (gvSIG e QGIS+GRASS). Per chiarire: ho gia’

preso contatto con quelli di ECDL-GIS, siamo a posto da quel punto di

vista. Va fatto un set di domande per ogni software (ovviamente, non

necessariamente devono essere diverse per ogni software, vanno solo

cambiati i riferimenti piu’ specifici).

pc

G. Allegri ha scritto:

Confermo l’impressione riguardo gvsig. E’ vero, non ha apparentemente

una struttura forte, ma in verit? ? un ottimo oggetto che vive in

silenzio (e in certi piani alti delle istituzioni). Anch’io non ci ho

fatto granch?, ma alcune cose mi hanno incuriosito:

  • positiva: buonissima gestione dei vettoriali

  • positiva: discreti tool per la georeferenzazione

  • positiva: pochi ma buoni tool per il trattamento delle immagini TLV

  • positiva: il supporto per ecw e dwg (opendwg)

  • cos?/cos?: scripting con python e xml (tra l’altro c’? un’ottima

guida sull’argomento) basato sul framework di gvsig, “Andami”.

  • negativo: l’elaborazione dei dati raster ? povera. non sono riuscito

a trovare neanche tool di map algebra… forse non li ho trovati ma

esistono, boh.

giovanni


Paolo Cavallini

http://www.faunalia.it/pc

-----BEGIN PGP SIGNATURE-----

Version: GnuPG v1.4.6 (GNU/Linux)

Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGVSnJ/NedwLUzIr4RAgULAJ95mBewkymwJDYUNE29dsPoEgN0tQCgj4xK

vWduU0SXcgASOTIolJX+hrI=

=d15s

-----END PGP SIGNATURE-----


Gfoss mailing list

Gfoss@faunalia.com

http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss


Gfoss mailing list

Gfoss@faunalia.com

http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss

Il problema con R è la continua variabilità dei comandi per
interfacciarsi a grass....
cambiano continuamente.... almeno questa è stata la mia esperienza nel
corso di questi ultimi 2 anni...
inoltre la portabilità...
Su Linux è facile integrare i due software...
su "finestre"??? non credo sia altrettanto facile.... (anche se o poca
esperienza in merito)....

ciao

Il giorno gio, 24/05/2007 alle 10.43 +0200, massimo di stefano ha
scritto:

are testing sui moduli q-grass per verificarne la funzionalità , e
apportare modifiche la dove necessario (..tipo ... mi serve un flag
che in grass c'è ma in qgis è nascosto...etc..) - vedere cosa manca
in qgis, ma che in grass c'è per eventuali aggiunte di moduli -
identificare tutti i processi e/o comandi che sono non facili da
utilizzare, o che richiedono l'utilizzo di moduli esterni (vedi
gdal-translate, pstoedit, ppmtompeg, e tanti altri..) - ricdercare
procedure "di uso comune" che richiedono l'utilizzo di piu comandi in
successione , creare script-grass che le automatizzino, e di
conseguenza aggiungere il modulo in qgis

scusate se il concetto può sebrare un po contorto, ma noi gli
strumenti li abbiamo, sono potenti quanto basta! ... bisogna solo
modellarli un pò

--
Ti prego di cercare di non inviarmi files .doc, .xls, .ppt, .dwg.
Preferisco formati liberi.
Please try to avoid to send me .doc, .xls, .ppt, .dwg files.
I prefer free formats.
http://it.wikipedia.org/wiki/Formato_aperto
http://en.wikipedia.org/wiki/Open_format

Ivan Marchesini
Department of Civil and Environmental Engineering
University of Perugia
Via G. Duranti 93/a
06125
Perugia (Italy)
e-mail: marchesini@unipg.it
        ivan.marchesini@gmail.com
tel: +39(0)755853760
fax (university): +39(0)755853756
fax (home): +39(0)5782830887
jabber: geoivan73@jabber.org