Ciao a tutti,
quest'anno il Google Summer of Code vede impegnati ben 5 italiani con OSGeo
[0]!
Il mio progetto prevede il porting del modulo GRASS v.autokrige in wxPython,
aggiungendo ulteriori funzionalità.
Vorrei chiedere a chi usa abitualmente il kriging, sia con GRASS, ArcGIS o R o
quant'altro, quali sono i casi d'uso più frequenti e i lati positivi/negativi
delle interfacce messe a disposizione dai vari programmi.
Il codice sarà disponibile sul repository SVN dei GRASS addons [1], in
particolare metterò a disposizione la bozza dell'interfaccia per il feedback.
grazie a tutti!
Anne
[0] http://socghop.appspot.com/org/home/google/gsoc2009/osgeo
[1] https://svn.osgeo.org/grass/grass-addons/vector/
--
Please consider the environment before printing this email
Please do not send attachments in proprietary formats
http://www.gnu.org/philosophy/no-word-attachments.html
Use the UNI CEI Standard ISO/IEC 26300:2006
-----------------------------------------------------------
O< stop html mail - http://www.asciiribbon.org
Anne Ghisla ha scritto:
quest'anno il Google Summer of Code vede impegnati ben 5 italiani con OSGeo
[0]!
Ci mancherebbe altro: la comunita' GFOSS italiana e' la piu' forte del
mondo! 
Il codice sarà disponibile sul repository SVN dei GRASS addons [1], in
particolare metterò a disposizione la bozza dell'interfaccia per il feedback.
Solo una cosa: io, dopo lungo rimuginio, sono *contrario* agli addons
per grass. In effetti quasi sempre i moduli, che dovrebbero stare in
addons come incubatore, mi sembra che ricevano pochissimo testing, e
quindi rimangano incubati per sempre. Qual e' il problema nel metterli
nel trunk (o, nel caso siano invasivi, in un branch)?
Saluti, e in bocca al topo a tutti!
--
Paolo Cavallini: http://www.faunalia.it/pc
On Monday 18 May 2009 14:52:21 Paolo Cavallini wrote:
Anne Ghisla ha scritto:
> quest'anno il Google Summer of Code vede impegnati ben 5 italiani con
> OSGeo [0]!
Ci mancherebbe altro: la comunita' GFOSS italiana e' la piu' forte del
mondo!
> Il codice sarà disponibile sul repository SVN dei GRASS addons [1], in
> particolare metterò a disposizione la bozza dell'interfaccia per il
> feedback.
Solo una cosa: io, dopo lungo rimuginio, sono *contrario* agli addons
per grass. In effetti quasi sempre i moduli, che dovrebbero stare in
addons come incubatore, mi sembra che ricevano pochissimo testing, e
quindi rimangano incubati per sempre. Qual e' il problema nel metterli
nel trunk (o, nel caso siano invasivi, in un branch)?
credo che dipenda abbastanza dalla pubblicità che gli si fa; se il lavoro
piace, ben venga che passi nel trunk.
Per l'inizio comunque gli addons mi sembrano il posto giusto. Ho un po' di
soggezione nei confronti del codice di GRASS
Saluti, e in bocca al topo a tutti!
crepi il topo 
--
Please consider the environment before printing this email
Please do not send attachments in proprietary formats
http://www.gnu.org/philosophy/no-word-attachments.html
Use the UNI CEI Standard ISO/IEC 26300:2006
-----------------------------------------------------------
O< stop html mail - http://www.asciiribbon.org
2009/5/18 Paolo Cavallini <cavallini@faunalia.it>:
...
Solo una cosa: io, dopo lungo rimuginio, sono *contrario* agli addons
per grass. In effetti quasi sempre i moduli, che dovrebbero stare in
addons come incubatore, mi sembra che ricevano pochissimo testing, e
quindi rimangano incubati per sempre. Qual e' il problema nel metterli
nel trunk (o, nel caso siano invasivi, in un branch)?
Per motivi vari serve una incubazione:
- mantenere la qualità di GRASS "main"
- evitare che sviluppatori nuovi mettono codice in trunk che
non è compatibile con la licenza di GRASS
- dare un testbed a quelli che sviluppano in gruppo senza
aprire trunk al "mondo"
- ...
Esempi:
- r.viewshed: bellissimo, velocissimo, ma con errore di precisione (vedi
test script nella cartella). Se lo mettessi in trunk oggi la gente
inizierebe
a sostituire il lentissimo r.los, ma poi accuserebbe GRASS di creare
dati sbagliati...,
- una serie di programmi non segue gli standards di GRASS come
descritti nei FILE SUBMITTING*.txt. Gli autori apparentemente non
hanno voglia di pulire il codice (nemmeno io),
- alcuni comandi sono senza documentazione,
- alcuni sono troppo specialistici (non vogliamo fare GRASS trunk
un "sourceforge" di roba non mantenuta). Bisognerebbe generalizzare
l'uso prima di metterli in trunk
Comandi messi in "main" di GRASS (vuol dire che c'è speranza):
- v.buffer
- v.delaunay
- r.horizon + r.sun
- ...
dopo la sistemazione dei loro problemi però.
Proposta/Soluzione:
- scrivere un meccanismo per integrare pacchetti di SVN-Addons tramite
script (vedi R extensions manager) - volunteers?
ciao
Markus
Markus Neteler ha scritto:
Proposta/Soluzione:
- scrivere un meccanismo per integrare pacchetti di SVN-Addons tramite
script (vedi R extensions manager) - volunteers?
Grazie per il chiarimento - molto logico.
Il meccanismo di R e' un vecchissimo sogno, ma nopn mi rendo conto di
quanto sarebbe difficile fare il porting o comunque replicarlo.
Saluti.
--
Paolo Cavallini: http://www.faunalia.it/pc