Salve , Per un lavoro che avevamo commissionato:ha usato qgis 1.8 Io sul mio computer ho qgis 2.2. QGIS Mi avvisa di cio' e mi effettua la trasformazione, ma il problema che ho è nella conservazione del risultato. Infatti il mio timore è che poi mi perda qualche trasparenza, o qualche dimensione cambi con il risultato che la carta che ne viene fuori divenga differente. Oltre tutto si tratta di carte a tutta toscana, tagliate a pezzettoni di 50K. Per cui è una impresa titanica andare a rivedersi punto punto le carte e confrontare i due risultati. Sono quindi alla ricerca di informazioni in merito a cos cambia dal punto di vista del trattamento delle vestizioni. Sta scritto da qualche parte cosa cambia alla resa grafica quando un progetto 1.8 viene aperto da un 2.0 o da un 2.2 ? In ogni caso questo fatto mi scatena una riflessione che girero' anche ai miei superiori. In merito alla reale opportunita di usare qgis per certe attività. Infatti se si fa' uno sforzo extra per costruire delle carte topografiche o anche di livello ctr usando qgis. NOn è accettabile che poi quando qgis passa alla versione successiva (e quindi se capisco bene dopo 4-5 mesi) il progetto diventa vecchio e se uno va ad aprire il vecchio progetto la resa grafica cambia !! Per chi lavora con le carte tecniche e con le carte topografiche sa bene che poter riprodurre una certa vestizione è essenziale. Forse qgis non è lo strumento adeguato per questo tipo di attivita ? E forse su questo fronte certi prodotti commerciali garantiscono una compatibilita' piu' ampia e anche piu' sicura dal punto di vista della conservazione dell'investimento ?
-- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 666 iscritti al 22.7.2013 |
Aggiungo un ulteriore tassello a questo raginamento. Se io facciouno sforzo per costruirmi una vestizione importante per delle carte importanti,Mi preoccupa anche perche' queste sono cose che uno non vede a occhio nudo se non confrontando due raster prodotti dai differenti sistemi qgis e controllandoli punto punto. A questo punto dovendomi porre la domanda di cosa fare per risolvere questo fatto. Il primo nome che mi viene in mente è "mapnik". Ho letto anche che è tostissimo da impostarre. Ma qui uno si potrebbe far aiutare da un plugin su qgis. Un plugin che esporti un progetto qgis in un progetto mapnik.... A. Il giorno 01 marzo 2014 08:13, Andrea Peri <[hidden email]> ha scritto:
-- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 666 iscritti al 22.7.2013 |
Salve.
Ragionamento importante, che richiede un'analisi approfondita. Butto giu' due considerazioni rapide, per ora. Il 01/03/2014 08:24, Andrea Peri ha scritto: > Se io facciouno sforzo per costruirmi una vestizione importante per > delle carte importanti, > se vado a riaprire il progetto un nno dopo, usando una versione > differente di qgis per l'ovvio fatto che nel frattempo è andato avanti, > e magari poiche' hanno risolte dei bachi su altre parti , sono costretto > a evolvermi il qgis per non dover convivere con tali bachi. Nessuno ti costringe: puoi usare quella versione per aprire quel progetto, e quella nuova per aprire una eventuale versione del progetto migrata alla nuova simbologia. . > Ma qui uno si potrebbe far aiutare da un plugin su qgis. > Un plugin che esporti un progetto qgis in un progetto mapnik.... https://plugins.qgis.org/plugins/quantumnik/ ? > QGIS Mi avvisa di cio' e mi effettua la trasformazione, > ma il problema che ho è nella conservazione del risultato. > > Infatti il mio timore è che poi mi perda qualche trasparenza, o > qualche dimensione cambi con il risultato che la carta che ne viene > fuori divenga differente. > Per cui è una impresa titanica andare a rivedersi punto punto le > carte e confrontare i due risultati. Rasterizzare gli output e confrontarli in modo automatico (ad es. con un raster calculator) e' piu' semplice ed efficace. > Sono quindi alla ricerca di informazioni in merito a cos cambia dal > punto di vista del trattamento delle vestizioni. > > Sta scritto da qualche parte cosa cambia alla resa grafica quando un > progetto 1.8 viene aperto da un 2.0 o da un 2.2 ? Puoi consultare i changelogs. Ovviamente le possibilita' grafiche sono sterminate, impossibile prevedere tutte le combinazioni, credo. > In merito alla reale opportunita di usare qgis per certe attività. > Infatti se si fa' uno sforzo extra per costruire delle carte > topografiche o anche di livello ctr usando qgis. > NOn è accettabile che poi quando qgis passa alla versione successiva > (e quindi se capisco bene dopo 4-5 mesi) il progetto diventa vecchio e > se uno va ad aprire il vecchio progetto la resa grafica cambia !! I cambiamenti che citi sono legati al cambio di major version (1>2). Non sono attesi all'interno della stessa versione. > Per chi lavora con le carte tecniche e con le carte topografiche sa > bene che poter riprodurre una certa vestizione è essenziale. > > Forse qgis non è lo strumento adeguato per questo tipo di attivita ? L'unico modo per essere sicuri che niente cambi e' non cambiare niente. Qualunque sw usi avra' dei miglioramenti, che sono pur sempre variazioni. > E forse su questo fronte certi prodotti commerciali garantiscono una > compatibilita' piu' ampia e anche piu' sicura dal punto di vista > della conservazione dell'investimento ? Non sono certo un esperto del settore, ma mi pare che il passaggio da una versione alla successiva del piu' noto sw del settore abbia causato lacrime e sangue, tant'e' che molti usano ancora la versione vecchia di 15 anni. In altri settori, mi pare che il passaggio da uno standard all'altro abbia causato non pochi problemi (e.g. SLD 1.0 > 1.1). Come tutte le cose, anche questo e' un problema reale che il sw puo' affrontare. Nessuno ne ha sentito l'esigenza finora, si tratta di vedere quale sia il problema e studiare forme di compatibilita'. Saluti. -- Paolo Cavallini - www.faunalia.eu QGIS & PostGIS courses: http://www.faunalia.eu/training.html _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 666 iscritti al 22.7.2013 |
Il giorno 01 marzo 2014 08:40, Paolo Cavallini <[hidden email]> ha scritto: Salve. La soluzione c'è e si chiama "test suite" e CI (integrazione continua). Di recente è stata introdotta in QGIS una suite di test, per ora decisamente limitata, che comprende test sul rendering confrontando i raster prodotti da un determinato set di feature.
Il progetto QGIS è cresciuto e i limiti e i difetti del modello di sviluppo open si fanno sentire, in fondo non ce lo siamo mai nascosto, ora li tocchiamo con mano. Detto questo, rimango assolutamente convinto che i problemi siano abbastanza facilmente risolvibili e che il modello di sviluppo open rimanga infinitamente superiore. Se ciascuno contribuisce, ce la possiamo fare, eccome! Alessandro Pasotti w3: www.itopen.it _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 666 iscritti al 22.7.2013 |
In reply to this post by pcav
Ti rispondo tra i punti.
On 01/03/2014 08:40, Paolo Cavallini wrote: > Salve. > Ragionamento importante, che richiede un'analisi approfondita. Butto > giu' due considerazioni rapide, per ora. Per affrontare il problema serve una comprensione a 360 gradi del problema Mi spiego tra i punti a seguire: > Il 01/03/2014 08:24, Andrea Peri ha scritto: > >> Se io facciouno sforzo per costruirmi una vestizione importante per >> delle carte importanti, >> se vado a riaprire il progetto un nno dopo, usando una versione >> differente di qgis per l'ovvio fatto che nel frattempo è andato avanti, >> e magari poiche' hanno risolte dei bachi su altre parti , sono costretto >> a evolvermi il qgis per non dover convivere con tali bachi. > Nessuno ti costringe: puoi usare quella versione per aprire quel > progetto, e quella nuova per aprire una eventuale versione del progetto > migrata alla nuova simbologia. Questa è una delle possibili soluzioni, ma non serve molto. Infatti il problema non è solo riaprire il progetto, ma anche evolverlo. Se dopo la verisone 1.8 è uscita la versione 2.0 è perche' hanno risolto dei bugs, ma anche che hanno introdotto delle evoluzioni. Se io uso sempre e solo la 1.8 per un detemrinato progetto grafico vuol dire che quel progetto è su un binario morto. Faccio un esempio semplice per cercare di chiarire: QGIS 1.8 non consentiva di gestire separatamente la trasparenza del bordo e dell'interno dei poligoni. Per cui se si è costruito una carta con qgis 1.8 SICURAMENTE non si è fatto di tale funzionalita' perche' non vi era. Questo comporta che la caeta è fatta in un certo modo. Se dopo un anno esce una nuova versione di QGIS che supporta la trasparenza di bordo e interno separatamente. Uno potrebbe pensare in una ottica di evololvere le proprie carte di introdurre tale comportamrnto in determinate circostanze. Per migliorare la carta. Ma se il solo fatto di passare da 1.8 a 2.0 comporta altri cambiamenti non voluti questo scoraggia perche' occorre rimettere mano al progetto e risistemare tutto cio' che non torna. . >> Ma qui uno si potrebbe far aiutare da un plugin su qgis. >> Un plugin che esporti un progetto qgis in un progetto mapnik.... > https://plugins.qgis.org/plugins/quantumnik/ ? Non lo so'. Mapnik non lo conosco per niente e non ho idea di quanto sia efficace. Non so' neanche se questa ipotesi sia fattibile. Il primo dubbio che mi viene è che cosi' facendo si perderebbe il vantaggio di un ambiente WYSIWYG >> QGIS Mi avvisa di cio' e mi effettua la trasformazione, >> ma il problema che ho è nella conservazione del risultato. >> >> Infatti il mio timore è che poi mi perda qualche trasparenza, o >> qualche dimensione cambi con il risultato che la carta che ne viene >> fuori divenga differente. >> Per cui è una impresa titanica andare a rivedersi punto punto le >> carte e confrontare i due risultati. > Rasterizzare gli output e confrontarli in modo automatico (ad es. con un > raster calculator) e' piu' semplice ed efficace. Appunto un lavoro da svolgere carta per carta e anche molto complesso. Dover mettere mano a una analisi dei rasters di due ambienti differenti per capire se il secondo ti ha introdotto delle differenze non è una bella prospettiva. >> Sono quindi alla ricerca di informazioni in merito a cos cambia dal >> punto di vista del trattamento delle vestizioni. >> >> Sta scritto da qualche parte cosa cambia alla resa grafica quando un >> progetto 1.8 viene aperto da un 2.0 o da un 2.2 ? > Puoi consultare i changelogs. Ovviamente le possibilita' grafiche sono > sterminate, impossibile prevedere tutte le combinazioni, credo. Infatti. E' come ipotizzare di leggersi il codice e risalite ai cambiamenti. Impossibile. >> In merito alla reale opportunita di usare qgis per certe attività. >> Infatti se si fa' uno sforzo extra per costruire delle carte >> topografiche o anche di livello ctr usando qgis. >> NOn è accettabile che poi quando qgis passa alla versione successiva >> (e quindi se capisco bene dopo 4-5 mesi) il progetto diventa vecchio e >> se uno va ad aprire il vecchio progetto la resa grafica cambia !! > I cambiamenti che citi sono legati al cambio di major version (1>2). Non > sono attesi all'interno della stessa versione. Puo' darsi che sia una intenzione. Ma non credo che sara' veramente mia presa in considerazione. Il passaggio dalla 1.8 alla 2.0 è avvenuto da poco e non fa' testo perche' appunto è un mabio di release. Ma io credo che anche tra la 2.x e la 2.(x+2) ci possono essere modifiche sostanziali. Staremo a vedere con il prossimo rilascio... Che tral'altro e' anche con il multithread. E poi mi pare di capire che anche sul fronte delle etichette si annunciano novita'... >> Per chi lavora con le carte tecniche e con le carte topografiche sa >> bene che poter riprodurre una certa vestizione è essenziale. >> >> Forse qgis non è lo strumento adeguato per questo tipo di attivita ? > L'unico modo per essere sicuri che niente cambi e' non cambiare niente. > Qualunque sw usi avra' dei miglioramenti, che sono pur sempre variazioni. > >> E forse su questo fronte certi prodotti commerciali garantiscono una >> compatibilita' piu' ampia e anche piu' sicura dal punto di vista >> della conservazione dell'investimento ? > Non sono certo un esperto del settore, ma mi pare che il passaggio da > una versione alla successiva del piu' noto sw del settore abbia causato > lacrime e sangue, tant'e' che molti usano ancora la versione vecchia di > 15 anni. Paolo, lo so bene che non possiamo parlare di queste cose perche' sono OT, pero' consentimi di spenderci una parola. In quel caso il problema non era la conservazione della vestizione, ma piuttosto l'abbandono di un software in favore di un altro. Come se te usi gvSIG per molti anni e poi passi a QGIS sarebbe comunque lacrime e sangue. Per cui il punto da capire e': A quali segmenti di lavoro si presta QGIS. Sicuramente ha una grande capacita' grafica. Ma puo' questo bastare , e puo' bastare avere una compatibilita' a livello di progetto qgis ? O serve anche la capacit'a di conservare l'aspetto grafico ? Questo punto qui ho l'impressione che non sia preso molto in considerazione. E' un uso abbastanza particolare, forse nessuno si e' posto questo problema prima. Ma ora che qgis comincia a affermarsi, occorre porsi queste domande. Ad esempio: se un soggetto fa'' un progetto e lo pubblica con qgis-server. 1.8. Se poi passa a qgis-server 2.0 e poi ancora a qgis-server 2.2. Che cambia nella parte grafica delle mappe ? Meglio sarebbe se niente cambiasse. Ma se qualcosa cambia . E' bene o è male ? Costringe a rimetterci mano e a rimettere le cose a posto ? Questi sono dubbi a cui prima o poi anche altri si scontreranno. La risposta non sempre è resta ancorato alla 1.8. Il rischio è che l'unica risposta sensata sia proprio resta con la tua vecchia versione. Questa risposta potrebbe anche nuocere piu' di quanto sembri. Perche' se un soggetto è incoraggiato a rimanere con una vecchia versione, non ha motivi per finanziare delle evoluzioni che tanto non sarebbero impiegabili proprio perche' legato a vecchie versioni. >L'unico modo per essere sicuri che niente cambi e' non cambiare niente. >Qualunque sw usi avra' dei miglioramenti, che sono pur sempre variazioni. Questo è un principio sacrosanto che nessuno discute. Il problema non è non cambiare, ma avere la percezione di cambiare in modo tale da non impattare sul lavoro degli altri. Questo è altrettanto importante. Prendi l'ambiente CAD ad esempio: A me non impensierisce un CAD che a ogni nuovo rilascio propon nuove funzionalita'. Ne mi impensierisce un cad che a ogni nuova versione di software rilascia anche una nuova versione del suo formato di drawing. Quello che mi aspetto pero' da un ambiente serio è che se vado ad aprire il file drawing vrsione 10,0 con il software targato versione 100.0 io vorrei vedere esattamente il medesimo risultato. Ovvero non vorrei scoprire che nel vecchio software una linea prima era tratteggiata e ora invece appare continua, perche nel frattempo dalla 10.0 alla 100.0 hanno cambiato modo di codificare il tratteggio. Se cio' avvenisse allora mi apsetterei che venga fatto anche un qualche tools che rimetta le cose a posto per chi proviene da una versione vecchia di file drawing. Forse dalla 10.0 alla 100.0 è troppo esagerato. Ma dalla 10.0 alla 11.0 sicuramente non è esagerato attendersi una cosa di tale genere. Questo forse è un dettaglio a cui viene posto maggiore attenzione nel mondo commerciale. Ovviamente parlo del mondo commericale dei prodotti seri. Quelli che si sono affermati grazie alla qualit'a dei prodotti, non alla bravura dei commerciali e a manovre di marketing spicciolo. Saluti, A. _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 666 iscritti al 22.7.2013 |
In reply to this post by Alessandro Pasotti-2
On Sat, Mar 01, 2014 at 11:21:53AM +0100, Alessandro Pasotti wrote:
> Il progetto QGIS è cresciuto e i limiti e i difetti del modello di sviluppo open si fanno sentire, s/open// Senza nessuna polemica, mi spiace ma in questa tua affermazione vedo un preconcetto legato al fatto che lo sviluppo open sia 'diverso' dallo sviluppo in genere. Cosa assolutamente falsa, prova ne sia che il problema deila conservazione dei formati e dei risultati del processing è un problema reale trasversale per strumenti open e proprietari. In un contesto completamente diverso - quello dei documenti - esiste un solo strumento che mi consti garantire esattamente il risultato finale dell'impaginazione (più o meno negli ultimi 30 anni) indipendentemente dalla versione, a meno di bug e si chiama TeX. E lo fa per un ottimo motivo, perché tale caratteristica è garantita by concept fin dall'inizio del suo ciclo di vita negli anni 70. Qualsiasi altro prodotto documentativo da questo punto di vista in confronto è fuffa, indipendentemente dal costo. Questa cosa non è senza un costo, ed il costo è questo: TeX è ritenuto dal suo creatore perfetto, con tutto quanto necessario e sufficiente ad ottenere un documento completo di qualsiasi lunghezza e complessità. Se l'utente non ci riesce il problema non è TeX, ma l'utente che non è in grado di concepire correttamente la soluzione implementativa, per quanto complessa essa possa essere. Temo che Qgis allo stato attuale sia molto lontano da tale Nirvana, e non credo nemmeno intenda arrivarci. E come Qgis il 90% di ogni altro software. Ergo è in definitiva questione di obiettivi e di conseguente workflow di sviluppo. In questo mondo imperfetto ci si può solo accontentare di prodotti imperfetti e di usare ogni volta la versione (imperfetta) adatta ad ottenere in modo ripetibile lo stesso risultato (imperfetto, ma sempre identico). Il vero problema è quindi: riesco ancora a far girare su una macchina del 2014 una versione 0.7.2 che mi serve per renderizzare i miei file di X anni fa? La risposta ovviamente è sì, basta installare una macchina virtuale Debian GNU/Linux di alcuni anni fa che pacchettizzava una versione 0.7.2 e risolvere il problema momentaneamente. Naturalmente entro un limite temporale ragionevole (dieci anni?), entro il quale ci si aspetta di migrare i dati a versioni up-to-date per ricominciare il ciclo. Just my 2 cents. -- Francesco P. Lovergine _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 666 iscritti al 22.7.2013 |
Molto interessante la citazione di TEX.
Purtroppo non conosco cosi' in profondita' qgis . Ma sarei tentato di pensare che il composer di qgis si prefiguri un po' come fa TEX con i suoi files di configurazione. Infatti la parte di interfaccia utente di qgis unita con la sua canvas è una interfaccia utente che potrebbe anche non esserci. L'importante è che ci sia un file di progetto di QGIS e un progetto di Composer. Il composer non fa' altro che prendere questi due files , unitamente a tutti i dataset citati nel progetto qgis e trasformarli in un file di output. Un output che puo' essere un pdf, ma anche un TIFF o una stampa diretta. Il giorno 01 marzo 2014 16:22, Francesco P. Lovergine <[hidden email]> ha scritto:
-- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 666 iscritti al 22.7.2013 |
In reply to this post by Francesco P. Lovergine
Il giorno 01 marzo 2014 16:22, Francesco P. Lovergine <[hidden email]> ha scritto:
Non è lo sviluppo ad essere diverso, sono le risorse e le motivazioni che spingono le persone a lavorare per il progetto. Io mi riferivo ai test e ad altre attività "noiose" (come per esempio aggiornare la documentazione, vedi i binding python). In un contesto aziendale, si prende un dipendente, lo si paga e gli si dice: ora tu scrivi i test.
In una comunità di volontari le cose non sono sempre così semplici, ovviamente questa è la mia impressione, che scaturisce dalla mia parzialissima e personalissima esperienza. Ammetto tra l'altro di avere una limitata conoscenza di come si svolge il processo di sviluppo in un ambiente non open, può essere che lo sopravvaluti. Concordo appieno sulle altre tue considerazioni. Alessandro Pasotti w3: www.itopen.it _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 666 iscritti al 22.7.2013 |
In reply to this post by Andrea Peri
On Sat, Mar 01, 2014 at 06:42:26PM +0100, Andrea Peri wrote:
> Molto interessante la citazione di TEX. > Questo è il famoso statement di Knuth di feature freezing per TeX e Metafont: http://tug.org/TUGboat/Articles/tb11-4/tb30knut.pdf Le considerazioni relative ai vantaggi di questo approccio le lascio a voi, ma quando io nel 2014 compilo qualcosa che ho scritto venti anni fa, il risultato è identico ad allora, che sia in PS o PDF (e il PDF venti anni fa praticamente non esisteva). Il che ha indubbi vantaggi pratici. > Purtroppo non conosco cosi' in profondita' qgis . > Ma sarei tentato di pensare che il composer di qgis si prefiguri un po' > come fa TEX con i suoi files di configurazione. > > Infatti la parte di interfaccia utente di qgis unita con la sua canvas è > una interfaccia utente che potrebbe anche non esserci. > L'importante è che ci sia un file di progetto di QGIS e un progetto di > Composer. > Il composer non fa' altro che prendere questi due files , unitamente a > tutti i dataset citati nel progetto qgis e trasformarli in un file di > output. > Un output che puo' essere un pdf, ma anche un TIFF o una stampa diretta. In qualche modo sì, il motore di rendering tratta oggetti diversi rispetto a quelli di TeX, e probabilmente (anzi sicuramente) non è monolitico come quello di TeX, ma per certi versi è simile. Dubito fortemente però che nessuno accetterebbe un freezing sine die del motore di rendering. Certo IMHO un ciclo di rilascio troppo rapido non aiuta a garantire un minimo di stabilità inter-versione. E quindi la scelta del ciclo di sviluppo ha la sua importanza. -- Francesco P. Lovergine _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 666 iscritti al 22.7.2013 |
In reply to this post by Alessandro Pasotti-2
On Sat, Mar 01, 2014 at 06:54:34PM +0100, Alessandro Pasotti wrote:
> Non è lo sviluppo ad essere diverso, sono le risorse e le motivazioni che > spingono le persone a lavorare per il progetto. Io mi riferivo ai test e ad > altre attività "noiose" (come per esempio aggiornare la documentazione, > vedi i binding python). In un contesto aziendale, si prende un dipendente, > lo si paga e gli si dice: ora tu scrivi i test. > Magari :-) Mica per caso anche nel mondo proprietario documentazione e test sono il punto dolente. Ancora una volta è questione di ciclo e modalità di sviluppo, non di soldi. Ed inoltre, non crederai che si dedichino persone a queste cose a cuor leggero? I soldi costano. > In una comunità di volontari le cose non sono sempre così semplici, > ovviamente questa è la mia impressione, che scaturisce dalla mia > parzialissima e personalissima esperienza. > Ti sembrerà strano, ma conosco nel mondo Debian un sacco di volontari che si dedicano ad attività per me noiosissime come traduzioni, documentazioni e quality assurance. Nel caso di Qgis il problema è più probabilmente il fatto che a tutt'oggi il team di contributori è piccolo. Paolo magari può dare su questo informazioni di prima mano. -- Francesco P. Lovergine _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 666 iscritti al 22.7.2013 |
In reply to this post by Francesco P. Lovergine
On 02/03/2014 15:49, Francesco P. Lovergine wrote:
> On Sat, Mar 01, 2014 at 06:42:26PM +0100, Andrea Peri wrote: >> Molto interessante la citazione di TEX. >> > Questo è il famoso statement di Knuth di feature freezing per TeX e Metafont: > http://tug.org/TUGboat/Articles/tb11-4/tb30knut.pdf > > Le considerazioni relative ai vantaggi di questo approccio le lascio a voi, > ma quando io nel 2014 compilo qualcosa che ho scritto venti anni fa, il > risultato è identico ad allora, che sia in PS o PDF (e il PDF venti anni > fa praticamente non esisteva). Il che ha indubbi vantaggi pratici. Eccezionale. Aveva anche codificato la regola per eventuali futuri rilasci con la sequenza del pi-greco. >> Purtroppo non conosco cosi' in profondita' qgis . >> Ma sarei tentato di pensare che il composer di qgis si prefiguri un po' >> come fa TEX con i suoi files di configurazione. >> >> Infatti la parte di interfaccia utente di qgis unita con la sua canvas è >> una interfaccia utente che potrebbe anche non esserci. >> L'importante è che ci sia un file di progetto di QGIS e un progetto di >> Composer. >> Il composer non fa' altro che prendere questi due files , unitamente a >> tutti i dataset citati nel progetto qgis e trasformarli in un file di >> output. >> Un output che puo' essere un pdf, ma anche un TIFF o una stampa diretta. > In qualche modo sì, il motore di rendering tratta oggetti diversi rispetto > a quelli di TeX, e probabilmente (anzi sicuramente) non è monolitico > come quello di TeX, ma per certi versi è simile. Dubito fortemente però > che nessuno accetterebbe un freezing sine die del motore di rendering. Sicuramente. Tra l'altro a quel che capisco allo stato attuale lo sviluppo di qgis è molto distribuito, e questo genere di cose richiedono invece una logica molto inquadrata e un pensiero unico. Non a caso Tex è un prodotto pensato e realizzato da una persona sola (Knuth). Certamente una persona molto particolare, ma è importante anche il fatto che operando in autonomia completa se lo è cucinato come voleva lui, senza interferenze. Ottimizzando ogni singolo passaggio , ogni singolo passo. Allargare la filiera avrebbe causato dispersione delle energie e perdita di vista dell'obiettivo. Vista da questo punto di vista QGIS è proprio agli antipodi. Assomiglia di piu' al moto degli elettroni in un conduttore. Presi singolarmente si muovono caoticamente in un intorno. Ma considerati tutti assieme e sottoposti a una energia potenziale, "mediamente" si muovono nella direzione del vettore di energia, ma sempre con urti e interferenze tra di loro. ... A. > Certo IMHO un ciclo di rilascio troppo rapido non aiuta a garantire > un minimo di stabilità inter-versione. E quindi la scelta del ciclo > di sviluppo ha la sua importanza. > _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 666 iscritti al 22.7.2013 |
In reply to this post by Francesco P. Lovergine
Il 02/03/2014 16:08, Francesco P. Lovergine ha scritto:
> e quality assurance. Nel caso di Qgis il problema è più probabilmente il fatto > che a tutt'oggi il team di contributori è piccolo. Paolo magari può dare > su questo informazioni di prima mano. Ci provo: * le idee, incluse le suites di tests, il sistema di pubblicazione che tienee in considerazione le regressioni come fattori bloccanti, ecc., ci sono tutte; ovviamente per farlo e' necessario un sacco di lavoro, ed e' vero che abbiamo sempre bisogno di nuovi sviluppatori (che fortunatamente continuano ad arrivare) * vedo la situazione attuale come un effetto dello sfalsamento fra l'adozione, ormai diffusa, in ambito enterprise, e il corrispondente investimento; e' abbastanza naturale che prima arrivino i problemi, poi gli investimenti, infine le soluzioni; le tendenze in queto senso sono incoraggianti (alcuni grossi enti stanno investendo in misura significativa), ma ovviamente andranno consolidate; e questo dipende anche da molti fra quelli che leggono questa lista: se chi usa QGIS in modo professionale ci reinveste una parte di quel che ha risparmiato, come fa la Regione Toscana ed altri, le soluzioni arriveranno presto e bene; se si concepisce il software libero come una cosa gratis, che va come va, su cui non intervenire, tutto andra' piu' lentamente. La stessa cosa e' successa pochi anni fa con l'adozione in ambito lavorativo di tipo small business; oggi direi che il problema in quel contesto e' sostanzialmente superato Salluti. -- Paolo Cavallini - www.faunalia.eu QGIS & PostGIS courses: http://www.faunalia.eu/training.html _______________________________________________ [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it. 666 iscritti al 22.7.2013 |
Free forum by Nabble | Edit this page |