[Gfoss] Compatibilita' Qgis - Grass (era: Qgis - malfunzionamento vettorializzatore del plugin grass)

Silvio Grosso grossosilvio a yahoo.it
Lun 29 Dic 2014 20:28:53 CET


Salve a tutti,

Luca Delucchi ha scritto:
> Mi spiace vedere come sempre più progetti se non c'è un investimento
> non mantengono feature già esistenti (che dal mio punto di vista è
> molto grave) o non ne implementino di nuove. 

Luca, capisco il tuo disappunto e concordo che e' un peccato che Grass non
sia sempre "integrato" al meglio in Qgis.
Leggendo la mailing list inglese degli sviluppatori di Qgis mi e' parso di
capire che la versione 7 di Grass potrebbe essere ancora piu' difficile da
gestire in Qgis.
Qualcuno ha notizie recenti a riguardo ?
C'e' qualche sviluppatore di Qgis che sta lavorando per integrare Grass 7 in
Qgis ?

Secondo me e' assolutamente "naturale" che alcune parti di Qgis siano
abbandonate in mancanza di opportuni finanziamenti economici.
Nel caso specifico di questa opzione (vettorizzazione del plugin Grass) non
penso neanche che sia cosi' grave perche', secondo me, sarebbe meglio
spingere gli utenti ad usare direttamente l'interfaccia grafica di Grass :-)
Siccome so che questa mia ultimissima "considerazione" potrebbe provocare
parecchie critiche (molte condivisibili) cerco di argomentare meglio cosa
intendo.

Come appassionato di fotoritocco uso da anni G'MIC.
G'mic comprende una raccolta di centinaia di filtri, oltre 600, da applicare
sulle proprie immagini [1]: funziona nativamente su Linux da linea di
comando su immagini jpeg, tiff ecc (8 bit, 16 bit, 32 bit ecc).
Attualmente e' possibile utilizzare G'mic anche con l'interfaccia grafica di
Gimp (http://www.gimp.org/) tramite un plugin.
Il problema della versione stabile attuale di Gimp 2.8.x e' che gestisce
bene solo le immagini, in particolare jpeg, con 8 bit per canale di colore.
La prossima versione stabile di Gimp, la 2.10, gestira' invece anche i file
con 16 bit - 32 bit ecc per canale di colore (Tiff - Raw ecc).
Purtroppo Gimp 2.10 potrebbe richiedere ancora diversi anni per essere
rilasciato.
Inoltre, per poter sfruttare questa nuova opzione, anche G'mic dovrebbe
essere adattato e questo comporta una enorme mole di lavoro.
Sia gli sviluppatori di Gimp che quello unico di G'mic lavorano
gratuitamente e questo giustifica i tempi lunghi e non prevedibili.

Recentemente G'mic e' stato incluso in Krita [2].
A me, all'inizio, e' parsa subita una evoluzione enorme rispetto a Gimp
perche' Krita gestisce da sempre i file Tiff e Raw (16 bit e 32 bit).
Purtroppo il mio entusiasmo iniziale e' man mano scemato perche' anche Krita
non sfrutta al meglio G'mic.
Molti filtri avanzati non funzionano e G'mic e' molto meglio integrato e
stabile in Gimp (jpeg) rispetto a Krita (jpeg + tiff, raw ecc)...
Gli sviluppatori open source di Krita hanno sempre incentivato le
sponsorizzazioni economiche degli utenti finali ma, attualmente, esse
bastano a malapena per 1 sviluppatore a tempo pieno [3].
G'mic e' quindi poco sviluppato e stabile in Krita anche perche' non ci sono
risorse economiche sufficienti per questo lavoro.
Krita ha oltre 300.000 linee di codice in C++ (senza considerare nel conto
le librerie Qt e di Kde) e servirebbero altri sviluppatori a tempo pieno per
stabilizzare e migliorare G'mic e tutte le altre funzionalita' [4]

Lo sviluppo software di G'mic con Gimp - Krita, secondo me, ricalca un po' i
problemi di Qgis - Grass...
Ecco perche' ritengo che gli utenti GIS dovrebbero essere sempre
"incentivati" a specializzarsi sopratutto nei vari software GIS (SpatiaLite,
PostGIS ecc...): il che ovviamente e' molto piu' dispendioso come tempo...
Nei software commerciali si nota spesso la stessa tendenza ad accentrare in
una unica applicazione diverse funzionalita' molto disparate tra loro.
Attualmente, per esempio, sia Microsoft Office (con Power Point) che
Photoshop permettono di effettuare delle piccole modifiche sui video...
In genere questo raggruppamento di opzioni avviene anche perche' "l'utente
medio" preferisce spesso avere tutte le funzionalita' in un unico software
(cosi' non si deve sforzare di apprendere troppi software...).

Scusatemi per il lungo messaggio che NON ha nessuna intenzione di suscitare
un coro di proteste.
Presumo infatti che siano veramente *pochissimi* gli utenti di questa lista
favorevoli a separare Grass da Qgis in futuro (e ne immagino le varie
ragioni...) :-)
Senza finanziamenti economici specifici temo pero' che difficilmente ci
possano essere grandi miglioramenti futuri (vedi messaggio iniziale)...

Cordiali saluti

Silvio Grosso

[1] http://gmic.eu/
[2] https://krita.org/item/krita-2-9-first-beta-released/
[3]
http://libregraphicsworld.org/blog/entry/boudewijn-rempt-on-the-state-of-affairs-with-krita-foundation
[4] http://www.valdyas.org/fading/index.cgi/kde/krita_10_years.html



--
View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Qgis-malfunzionamento-vettorializzatore-del-plugin-grass-tp7590942p7590993.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.


Maggiori informazioni sulla lista Gfoss