+1 Francesco, condivido pienamente la tua analisi!<div>OTB č un progetto piuttosto dinosaurico, e non so quanto sarā facile far passare questo approccio... ma ne va sicuramente del suo potenziale impiego in altri progetti, come Qgis.</div>
<div><br></div><div>giovanni</div><div><br><div class="gmail_quote">Il giorno 28 ottobre 2011 12:48, Francesco P. Lovergine <span dir="ltr"><<a href="mailto:frankie@debian.org">frankie@debian.org</a>></span> ha scritto:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Fri, Oct 28, 2011 at 11:26:23AM +0200, Sandro Santilli wrote:<br>
> Se non sbaglio qualcuno ha tirato fuori OTB durante la presentazione<br>
> che ho fatto ieri al JRC (doveva essere sulla topologia in PostGIS ma<br>
> come sempre succede quando presento io e' andata a parare in generale<br>
> sul software libero :)<br>
><br>
> In particolare qualcuno ha citato OTB in risposta ad un'intervento che<br>
> sosteneva ci fossero casi in cui il software proprietario e'<br>
> "piu' avanti" rispetto a quello libero su certi specifici algoritmi.<br>
> Potrei sbagliarmi, prego Paolo Corti di correggermi in questo caso.<br>
><br>
> Insomma, pare valga la pena investire in questo OTB.<br>
> Qualcuno ha notificato il problema upstream ?<br>
> C'e' un ticket per affrontarli ?  <a href="http://bugs.orfeo-toolbox.org" target="_blank">http://bugs.orfeo-toolbox.org</a><br>
><br>
<br>
</div>Ossim e OTB sono difatto tra i pochi prodotti remote sensing FOSS,<br>
ed ha effettivamente alcuni algoritmi di notevole spessore implementati.<br>
La notifica l'ho giā fatta da tempo via canale irc e ML ed č un problema<br>
noto, ma che non si risolve in due minuti.<br>
Peraltro č un problema comune legato al modus operandi di progetti<br>
che hanno necessitā di 'stare sul problema' e tendono ad essere<br>
autarchici nella gestione delle dipenze (javari malefici in testa :-P).<br>
<br>
Sfortunatamente IMHO questo approccio - che č una ereditā del mondo proprietario -<br>
cozza alla grande con lo stile di sviluppo FOSS. In altri contesti (leggi<br>
kernel ad esempio) si č capito da un pezzo che il tracking delle dipendenze<br>
e un puntuale e continuo feedback da e verso i progetti upstream č l'unico<br>
modo per fare il proprio sviluppo senza dover anche mantenere il fork<br>
di source tree altrui ad libitum. In altre parole č un approccio che alla<br>
lunga non scala.<br>
<br>
Dal punto di vista di chi poi integra le soluzioni - come i distibution developer -<br>
il tutto č poi un non-sense e contrario a qualsiasi buona pratica.<br>
<font color="#888888"><br>
--<br>
Francesco P. Lovergine<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
Iscriviti all'associazione GFOSS.it: <a href="http://www.gfoss.it/drupal/iscrizione" target="_blank">http://www.gfoss.it/drupal/iscrizione</a><br>
<a href="mailto:Gfoss@lists.gfoss.it">Gfoss@lists.gfoss.it</a><br>
<a href="http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss" target="_blank">http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss</a><br>
Questa e' una lista di discussione pubblica aperta a tutti.<br>
Non inviate messaggi commerciali.<br>
I messaggi di questa lista non rispecchiano necessariamente<br>
le posizioni dell'Associazione GFOSS.it.<br>
527 iscritti al 7.7.2011</div></div></blockquote></div><br></div>