Re. dipendenza da software proprietario
Locked
12
12
Re. dipendenza da software proprietario
 
|
>Beh, stanchi? >Dopo una giornata al mare io sono fresco e riposato :-) > >Contributo su una discussione ormai alla fine: nel mio lavoro la >rappresentazione grafica copriva il 5% dei costi dell'intera commessa >di produzione cartografica e pubblicazione su internet. > >Si trattava di pubblicare su internet piani urbanistici (PRG, PUTT, >ecc.) nati decenni fa, e per contratto dovevo riprodurre alla lettera >le campiture, i tratteggi, i colori, le dimensioni relative, ecc. in >modo che i geometri (interni ed esterni al comune) avessero meno >difficoltà possibile nel passare dalla carta stampata al webGIS. > >Centinaia di campiture le più strampalate: mattoni, ciuffetti d'erba, >rigati a passo di samba... :-) >Siamo rimasti su Mapserver, ritardando il passaggio a Geoserver, >proprio per la difficoltà di ricostruire tutta quella libreria di >simboli con gli SLD. > >Il pennino di Mapserver è stato molto flessibile, ma anche un po' ostico... >Spero di poterci mettere mano un giorno per trasformare tutti quei >simboli in formato SLD. Ora mi sto occupando di altro. > >In lavori di questo tipo i dati contano tantissimo, è vero (si parla >di dove si può costruire e dove no...), ma anche la loro facilità di >lettura e aderenza ad un asimbologia preesistente contano tanto. > >Ciaociao >Vitomeuli Ciao Vito, il tuo rilancio e' molto interessante. Infatti un esperto che non ho mai saputo è che nella rappresentazione geologica contasse anche le dimensioni dei pennini. Credevo che fossero piu' rivolte all'impiego dei colori e del simbolismo grafico. Da noi, invece, prevale il punto di vista cartografico ovviamente. E come ti potrebbe dire qualche mio collega la cartografia ha impiegato secoli per stabilire la grafia. Ora come ora la cartografia nella rappresentazione digitale fa' un grande uso di forme e spessori e non usa mai i colori. Tornando all'argomento. Nella cartografia della CTR vengono definiti simboli tratteggi e spessori. Tutta roba espressa in mm. Ad esempio in una ctr 2k lo spartitraffico deve avere spessore 0,13 mentre la strada non asfaltata spessore 0,18 e il sentiero spessore 0,25. Per non parlare dei tipi di tratteggio, ove i cartografi si sono sbizzarriti oltre misura. Ad esempio la ferrovia in disuso e' espressa da una linea con spessore 0,35 con un tratteggio 3 / 0.5 / 0.5, o il faro (spessore 0,18 con tratteggio 1/1) E qui arriva uno dei problemi tipici della rappresentazione cartografica al computer. Come fare a riprodurre rispettando tali regole ? Anche solo limitandosi allo spessore, i problemi non sono pochi. Come riportare delle differenze tra 0,13 - 0,18 - 0,25 etc... In un sistema rappresentativo in cui le dimensioni sono 1px, 2px, 3px ? Qui certamente vi e' un problema. Il tuo intervento e' interessente per me perche' te dici: >Siamo rimasti su Mapserver, ritardando il passaggio a Geoserver, >proprio per la difficoltà di ricostruire tutta quella libreria di >simboli con gli SLD. > >Il pennino di Mapserver è stato molto flessibile, ma anche un po' ostico... >Spero di poterci mettere mano un giorno per trasformare tutti quei >simboli in formato SLD. Ora mi sto occupando di altro.Sapere che esistono delle differenze in questo senso tra MapServer e Geoserver per me e' molto importante. Infatti in questo periodo mi stavo accingendo a testare mapnik. Avevo letto da qualche parte che Mapnik e' molto sofisticato e quindi volevo vederne le reali capacità. Il tuo intervento pero' mi ha decisamente incuriosito nei confronti di MapServer. Mi pare invece di capire dal tuo intervento che GeoServer come capacita' grafica e' inferiore a entrambi. Cosa centra tutto questo con la dipendenza dal software proprietario ? Centra nella misura in cui per riprodurre una tale grafia si deve abbandonare il GIS propriamente detto e rivolgersi al mondo CAD. Fino ad ora pensavo che questa esigenza di graficismo spinto fosse una esigenza specifica dei cartografi. Quindi una nicchia di persone . Invece mi pare di capire dal tuo e da interventi precedenti che anche i geologi hanno questa esigenza di riprodurre carte con segni e regole di tracciatura molto rigorose, dove li spessori e le regole di tratteggio imperano e la fanno da padrona. Questo mi spinge a pensare che come i cartografi, anche i geologi per riprodurre una carta corretta secondo certe regole grafiche, dovrebbero fare ricorso a mezzi CAD. A meno di non fare cose approssimate e probabilmente sempre contestabili . Ma non ho mai visto un geologo lavorare con un sistema Cad (commerciale o no). E allora come sta' la faccenda ? -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
|
|
Eh sì, Andrea, sono questioni che riguardano anche i geologi ;)
Finora non ho trovato soluzioni gis open ad una gestione avanzata della vestizione cartografica. Magari è solo questione d'ignoranza, ma per ora, per cose un po' "spinte", mi trovo a dover usare sw proprietari (non cito il nome per non fare pubblicità), che mi permettono di gestire in modo fine-grained anche i più piccoli dettagli, e a lavorare in dimensioni metriche esatte come le vedrò in output di stampa su plotter... I valori frazionali magari non si percepiscono lei loro rapporti esatti a schermo, ma su carta sì.
giovanni
Il giorno 10 aprile 2011 21:33, Andrea Peri <[hidden email]> ha scritto: >Beh, stanchi? >Dopo una giornata al mare io sono fresco e riposato :-) > >Contributo su una discussione ormai alla fine: nel mio lavoro la >rappresentazione grafica copriva il 5% dei costi dell'intera commessa >di produzione cartografica e pubblicazione su internet. > >Si trattava di pubblicare su internet piani urbanistici (PRG, PUTT, >ecc.) nati decenni fa, e per contratto dovevo riprodurre alla lettera >le campiture, i tratteggi, i colori, le dimensioni relative, ecc. in >modo che i geometri (interni ed esterni al comune) avessero meno >difficoltà possibile nel passare dalla carta stampata al webGIS. > >Centinaia di campiture le più strampalate: mattoni, ciuffetti d'erba, >rigati a passo di samba... :-) >Siamo rimasti su Mapserver, ritardando il passaggio a Geoserver, >proprio per la difficoltà di ricostruire tutta quella libreria di >simboli con gli SLD. > >Il pennino di Mapserver è stato molto flessibile, ma anche un po' ostico... >Spero di poterci mettere mano un giorno per trasformare tutti quei >simboli in formato SLD. Ora mi sto occupando di altro. > >In lavori di questo tipo i dati contano tantissimo, è vero (si parla >di dove si può costruire e dove no...), ma anche la loro facilità di >lettura e aderenza ad un asimbologia preesistente contano tanto. > >Ciaociao >Vitomeuli _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
|
In reply to this post by Andrea Peri
Il 10 aprile 2011 21:33, Andrea Peri <[hidden email]> ha scritto:
... > Mi pare invece di capire dal tuo intervento che GeoServer come capacita' > grafica e' inferiore a entrambi. > Non intendevo dire questo. Volevo dire che il bagaglio culturale e la libreria di simboli che ci siamo costruiti a manina in 6 anni di esperienza (visto che per Mapserver non ne abbiamo trovate) erano difficili da rimpiazzare usando una tecnologia diversa (gli SLD) probabilmente anche superiore, ma a noi sconosciuta. E i vantaggi (altri) di Geoserver non erano tali da spingerci ad accelerare in quella direzione più di tanto. > Cosa centra tutto questo con la dipendenza dal software proprietario ? > > Centra nella misura in cui per riprodurre una tale grafia si deve > abbandonare il GIS propriamente detto e rivolgersi al mondo CAD. non so se esisterà mai un webCAD :-) > Fino ad ora pensavo che questa esigenza di graficismo spinto fosse una > esigenza specifica dei cartografi. > Quindi una nicchia di persone . > Invece mi pare di capire dal tuo e da interventi precedenti che anche i > geologi hanno questa esigenza di riprodurre carte con segni e regole di > tracciatura molto rigorose, > dove li spessori e le regole di tratteggio imperano e la fanno da padrona. Il webGIS è necessariamente semplificato rispetto alla stampa, ma non per questo banalmente a tinte piene: dove i retini si devono sovrapporre ed essere tutti contemporaneamente leggibili, bisogna curare l'aspetto estetico, perché veicola parte dell'informazione. E se di questo prodotto cartografico esistono contemporaneamente la versione a stampa e la versione webGIS, la coerenza grafica tra le due è d'obbligo. Questo mi sembra un punto importante. Chi ha progettato la vestizione grafiche decenni prima di me ha avuto i suoi buoni motivi per scegliere quelle campiture, e io devo rispettare le sue scelte. > > Questo mi spinge a pensare che come i cartografi, anche i geologi per > riprodurre una carta corretta secondo certe regole grafiche, > dovrebbero fare ricorso a mezzi CAD. > A meno di non fare cose approssimate e probabilmente sempre contestabili . > > Ma non ho mai visto un geologo lavorare con un sistema Cad (commerciale o > no). > > E allora come sta' la faccenda ? La faccenda secondo me sta così: una persona non può pretendere di conoscere il mondo solo perché lo osserva tutti i giorni fuori della sua finestra; ci sono posti lontani e completamente diversi; e pure dopo che ha viaggiato tutta una vita, prima di dire "questa cosa non esiste" ci deve pensare bene. Gli strumenti GIS hanno utilizzi molteplici, gli utilizzatori non sono tutti nè geologi, nè archeologi, nè topografi, nè urbanisti nè giocatori del Risiko. il 98% degli utilizzatori magari degli spessori non ne ha bisogno, però qualcun altro si. Lo si vuole supportare? Si lavora e lo si supporta. La democrazia di molte comunità opensource è fantastica su questo punto. Mapserver lo conosco bene, e fa tutto quello che il mio collega cartografo mi ha mai potuto chiedere. Cose che fior di SW GIS innominabili si possono sognare (a detta sua, che usa i più noti e costosi). Sono convinto che SLD sia capace di esprimere le vestizioni altrettanto bene, ma non lo so, non sono arrivato a studiarlo a fondo. Il formato deputato a diventare lo standard della vestizione mi aspetto che sia molto completo. E spero che Geoserver supporti tutto l'SLD, anche le cose più esotiche. Anche questo non lo so. Se qualcuno lo sa ci può illuminare, o dovrai chiedere su altre liste più specifiche. I miei due cent. Ciaociao Vito _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
|
|
On Mon, 11 Apr 2011 00:17:07 +0200, Vito Meuli wrote
> Il 10 aprile 2011 21:33, Andrea Peri <[hidden email]> ha > scritto: ... > > > Cosa centra tutto questo con la dipendenza dal software proprietario ? > > > > Centra nella misura in cui per riprodurre una tale grafia si deve > > abbandonare il GIS propriamente detto e rivolgersi al mondo CAD. > > Il webGIS è necessariamente semplificato rispetto alla stampa, ma > non per questo banalmente a tinte piene: dove i retini si devono > sovrapporre ed essere tutti contemporaneamente leggibili, bisogna > curare l'aspetto estetico, perché veicola parte dell'informazione. > E se di questo prodotto cartografico esistono contemporaneamente la > versione a stampa e la versione webGIS, la coerenza grafica tra le > due è d'obbligo. Questo mi sembra un punto importante. > Ullalà, finalmente ho capito di cosa stiamo parlando: un bel GRAZIE ad Andrea che ha sollevato la questione, ed a Vito che ha esposto così chiaramente il problema. BTW veramente interessante questa discussione: siamo partiti un po' "alla farfallona" con la solita flame war inconcludente e poco costruttiva, ed invece alla fine qualcosa di serio ed importante è venuto fuori. Riassumo (a beneficio mio, più che altro): esistono alcune particolari nicchie applicative (le carte geologiche in primis, ma probabilmente non solo quelle) in cui servono assolutamente stili grafici ben più complicati e raffinati del solito armamentario standard che si usa normalmente per i casi più banali. Probabilmente il sw libero ha ancora un bel pezzo di strada da fare su questo terreno particolare. Sicuramente non è un problema di assoluta priorità (probabilmente interessa solo una categoria molto particolare di utenti), ma certamente è bene essere consapevoli del problema. Io personalmente ho scoperto solo oggi che esiste; a mia personale memoria, negli ultimi anni non mi è mai capitato neppure una singola volta di leggere un post relativo a questo argomento. Piccola soddisfazione personale: finalmente ho risolto un antico interrogativo che mi risultava assolutamente incomprensibile. Negli ultimi anni mi è capitato almeno una decina di volte di parlare con svariati geologi; ed invariabilmernte tutti loro mi hanno detto: "uso QGIS e/o gvSIG per diversi lavori, mi ci trovo anche bene, ma per le stampe fanno schifo, devo usare per forza l'innominabile". sono curioso per mia natura; tutte le volte ho chiesto: "e perchè le stampe farebbero schifo ?" risposta (giuro): "dai, fanno schifo e basta. lo sanno tutti che il sw open source per le stampe non è proprio all'altezza, e che bisogna utilizzare per forza l'innominato che per questi lavori è insuperabile". Oggi, grazie alla chiara spiegazione di Vito, finalmente (forse) ho capito cosa intendevano dire veramente. Lesson to learn: le community servono anche per questo. Se chi ha un problema specifico, e magari di nicchia, non ne parla mai con la propria community e con gli sviluppatori (possibilmente esponendo le proprie esigenze con un minimo di dettaglio articolato), poi è del tutto ovvio che il problema rimarrà irrisolto (ed ignorato) per omnia saecula saeculorum :-) ciao, Sandro _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
|
|
Il 11 aprile 2011 01:01, <[hidden email]> ha scritto:
> Se chi ha un problema specifico, e magari di > nicchia, non ne parla mai con la propria community > e con gli sviluppatori (possibilmente esponendo le > proprie esigenze con un minimo di dettaglio > articolato), poi è del tutto ovvio che il problema > rimarrà irrisolto (ed ignorato) per omnia saecula > saeculorum :-) Amen! :-) Ciaociao Vitomeuli --- https://sites.google.com/site/vitomeuli/ _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
Re: Re. dipendenza da software proprietario
|
|
In reply to this post by Andrea Peri
Ci ho messo un ora stamani a leggere tutto, ma un contributo (tardivo) mi
scappa sul tema estetica-vestizione. Concordo con la questione che non si tratta di estetica, ma di comunicazione dell'informazione. Se questo non bastasse a sostenerne l'importanza aggiungo che in alcuni casi questa comunicazione non è solo estetica, ma ha valore legale. Il caso è precisamente quello dei retini dei piani regolatori del mail di Vito. Esempio, semi-reale: ti chiama un comune e ti chiede di elaborare una cartografia di piano regolatore con dati gis, magari ti chiede anche di produrre i dati, o semplicemente di controllarne la correttezza. Va da se che restituire una serie di shp o geodatabase "corretto" è fondamentale, ma poi devi produrre una carta che verrà stampata e quella ha valore normativo. Spesso finisce che si consegnano shp e un PDF, ma se il comune ha un minimo di capacità di programmazione si pone anche il problema che magari fra un anno cambia una parte della tavola e del pdf non se ne fa più niente, quindi preferisce avere la vestizione in un formato non solo utile alla stampa. Questo non significa che la si debba fare con il software X piottosto che Y, ma che la richiesta non è strana. Sulla scelta del software cosa pesa dunque (non parlo di soluzioni web di cui non so niente). Sicuramente il repertorio di simboli e campiture che uno si è fatto nel tempo, magari iniziando a lavorare su software proprietario, semplicemente perché non aveva idea di come usare quello libero e manco che esistesse all'inizio (capita), poi magari si fa una più raffinata analisi delle potenzialità di diverse soluzioni e qui credo che margini di milgioramento nel mondo libero ce ne siano. Per finire riporto per esperienza personale che comunque si può essere incaricati anche solo ed esplicitamente per la propria competenza nella vestizione e spenderci parecchie settimane (tre mesi di lavoro, non del tutto ful time, in 2 per 2 carte, compresa un po' di lavoro sui dati tanto per fare un esempio concreto di un po' di anni fa). Buona settimana a tutti. Iacopo Zetti _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
|
|
Il giorno lun, 11/04/2011 alle 10.01 +0200, [hidden email]
ha scritto: > normativo. Spesso finisce che si consegnano shp e un PDF, ma se il comune > ha un minimo di capacità di programmazione si pone anche il problema che > magari fra un anno cambia una parte della tavola e del pdf non se ne fa > più niente, quindi preferisce avere la vestizione in un formato non solo > utile alla stampa. Mi sfugge un punto: la vestizione il comune non ce l'ha gia'? Intendo: se le frane si rappresentano con i puntini, non e' mica il professionista a dover fornire lo stile di rappresentazione: immagino che l'ente abbia gia' una sua rappresentazione (magari comune a tutta la regione), non che ogni professionista se la debba rifare. Il problema si pone per la consegna di un webgis, o di un'applicazione che deve produrre un output, ma non per la consegna dei dati, no? Quindi, proposta: condividiamo il patrimonio di simboli che ognuno di noi ha fatto, ognuno per la sua amministrazione? Un primo passo in questo senso e' stato fatto anni fa, grazie a Iacopo Zetti, Giuseppe Patti e Silvio Grosso: http://gfoss.it/drupal/simboli E' il caso di proseguire, creando un minimo di infrastruttura per la condivisione (up- e download, rating, editing collaborativo, ecc.). Commenti? volontari? Saluti. -- http://www.faunalia.it/pc _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
|
|
La condivisone della simbologia è senz'altro un aspetto importante, tuttavia forse potrebbe essere utile coordinare un lavoro congiunto per definire quali aspetti tecnologici ci sembrano carenti nell'ambito della vestizione cartografica di questo tipo.
A suo tempo avevo iniziato a studiare GMT [1], ma è veramente un universo parallelo! :) Anche gli innominabili, pur offrendo funzionalità più complete e avanzate dal punto di vista cartografico, talvolta necessitano di un'ulteriore elaborazione in sw di grafica esterni. Al di là del colmare questo divario (da definire meglio), c'è anche margine per migliorare l'esperienza utente in termini di output finale di livello professionale.
Servono risorse di sviluppo notevoli, ma intanto potremmo elencare 'cosa ci manca'. Buona giornata, giovanni [1] http://www.soest.hawaii.edu/gmt/
Il giorno 11 aprile 2011 10:11, Paolo Cavallini <[hidden email]> ha scritto: Il giorno lun, 11/04/2011 alle 10.01 +0200, [hidden email] _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
Re: Re. dipendenza da software proprietario
|
|
In reply to this post by pcav
Il giorno 11/apr/2011, alle ore 10.11, Paolo Cavallini ha scritto: > > Mi sfugge un punto: la vestizione il comune non ce l'ha gia'? Non sempre, non necessariamente. > Intendo: > se le frane si rappresentano con i puntini, non e' mica il > professionista a dover fornire lo stile di rappresentazione: beh, invece anche si. Dipende CHI e' il professionista. Se il professionista e' "solo" quello che implementa il GIS o il WebGIS, potrebbe anche essere, nel senso che il tecnico si aspetta che qualcuno gli dica come deve fare lo stile di rappresentazione. Ma molte volte la definizione di un particolare stile di rappresentazione e' qualcosa che NASCE, o meglio "si definisce, si raffina, si migliora" nel momento in cui si va a compilare la base dati. Ripeto, la rappresentazione del dato FA parte della base dati, ha la stessa importanza della topologia o del DB alfanumerico, anzi deve essere spesso definita da un apposito DB, e spesso viene costruita "di conserva" alla costruzione della base dati GIS. Molte volte il problema e' anche dettato dalle possibilita' tecniche del software, nel senso che se una determinata informazione che si vuole veicolare graficamente non si puo' fare perche' il tool scelto non me lo permette, si lavora fianco a fianco tra tecnici con varie competenze per produrre un set di dati fruibile e comprensibile per gli scopi prefissati. > Il problema si pone per la consegna di un webgis, o di un'applicazione > che deve produrre un output, ma non per la consegna dei dati, no? Si e no. Gia' i dati devono prevedere regole, gerarchie, campi e attributi volti alla rappresentazione grafica. Le priorita', ad esempio, di una campitura rispetto ad un'altra, chi deve sempre stare sopra e chi sempre sotto, come si fondono i margini di due tematismi sovrapposti... Questo vale in geologia ma anche in cartografia "pura". Ho avuto modo di lavorare con dei geodatabase di importanti ditte di cartografia italiana. Immaginate quanti campi di database devono essere utilizzati per far si che l'output grafico di una carta Touring in scala 1:250.000 sia leggibile (autostrade che passano sopra o sotto strade statali, o si spostino a lato, "falsificando" la topologia ai fini grafici.... gestione dei ponti, dei sovra e dei sottopassi....), e lo stesso geodatabase sia in grado di produrre una cartografia in scala 1:100.000 o 1:500.000 adeguatamente leggibile. Questi problemi, ad esempio, ce li ha OpenStreetMap, e vengono presi in considerazione (non in maniera perfetta, ma comunque buona, a mio parere). Il GIS non e' "solo" dati, o meglio, i dati del GIS non includono "solo" le topologie e gli attributi piu' "ovvi". Gli attributi relativi alla visualizzazione sono altrettanto importanti, in innumerevoli casi. > E' il caso di proseguire, creando un minimo di infrastruttura per la > condivisione (up- e download, rating, editing collaborativo, ecc.). > Commenti? Il primo commento che mi viene da fare e' che e' impensabile definire uno STANDARD unico che contempli tutte le possibile casistiche cartografiche, a tutte le scale. E' velleitario e non tiene conto di n mila parametri, alcuni prettamente umani e biechi (gelosie, rivalita', visioni del mondo), altri piu' tecnici (troppi e troppo diversificati sono i paradigmi da prendere in considerazione. All'interno della stessa cartografia geologica un conto e' ragionare sulla carta al 5.000, un conto e' la carta al 10.000, ad esempio. E potrei fare altri n mila esempi). Questo pero' non significa che un lavoro di condivisione e proposte di uniformazione non siano gia' state fatte e la strada non possa essere percorsa, almeno fino a un certo punto. Con la consapevolezza pero' che ci sara' sempre un punto in cui si dovra' lasciare il sentiero comune ed entrare nella personalizzazione. Ah, cosi' giusto per gradire, uscendo un attimino dal topic. I geologi sarebbero MOLTO contenti di avere un tool cartografico che disponga il retino delle frane (le cosiddette TEGOLINE) non in maniera isotropa, ma lo ruoti automaticamente in funzione dell'esposizione dei versanti. Questo perche' le tegoline mi farebbero capire a prima vista come si muove la frana. Questo e' il classico esempio di simbologia che porta informazione e che e' intrinsecamente legata alla tipologia di dato. Questa cosa, ai miei tempi (oddio... ho solo 45 anni...) si faceva senza problemi a mano disegnando le tegoline sopra le isoipse. Con i vari tool software, GIS o CAD o Desk Top Mapping, al momento, non sono ancora riuscito a farla in automatico anche se ci sto provando (definizione di micropattern ripetibili e deformabili che siano correlati all'aspect del DEM sottostante....). Quante belle cosine che ci sono ancora da fare per arrivare a disporre della versatilita' e della comunicativita' che ci dava la mano libera! :) Ciao Marco GEOgrafica _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
Re: Re. dipendenza da software proprietario
|
|
In reply to this post by Andrea Peri
Il giorno 10/apr/2011, alle ore 23.03, G. Allegri ha scritto:
> > Ciao Vito, > > il tuo rilancio e' molto interessante. > > Infatti un esperto che non ho mai saputo è che nella rappresentazione geologica contasse anche le dimensioni dei pennini. > Credevo che fossero piu' rivolte all'impiego dei colori e del simbolismo grafico. > > Da noi, invece, prevale il punto di vista cartografico ovviamente. > E come ti potrebbe dire qualche mio collega la cartografia ha impiegato secoli per stabilire la grafia. > Ora come ora la cartografia nella rappresentazione digitale fa' un grande uso di forme e spessori e non usa mai i colori. ? Non ho capito bene questo discorso. In quale cartografia non si usano MAI i colori? Nelle cartografie topografiche bianco/nero, forse. Ma queste sono solo UN tipo di cartografie. Direi che il 90% delle cartografie, sia topografiche che tematiche, fanno larghissimo uso del colore e necessitano quindi di attenzione alla vestizione, non tanto (o non solo) per l'aspetto estetico ma per l'aspetto informativo e comunicativo. Vedi esempi CARG postati da F. Marucci e elaborati in B/N da A. Furieri con risultati erronei e con perdita di informazione. > > Tornando all'argomento. > Nella cartografia della CTR vengono definiti simboli tratteggi e spessori. Tutta roba espressa in mm. > E qui arriva uno dei problemi tipici della rappresentazione cartografica al computer. > Come fare a riprodurre rispettando tali regole ? [cut] Le considerazioni che fai sono giuste e interessanti, e sono intrinsecamente collegate al concetto di SCALA e al concetto di VALIDITA' del dato. Lavorando con i GIS da un punto di vista prettamente informatico e rimanendo su supporto informatico, si ha talora la tendenza a perdere di vista il fatto che la SCALA di acquisizione, quantizzazione, visualizzazione, riproduzione... non e' un concetto aleatorio o ininfluente, ma e' anzi basilare a dare significato e validazione ai dati che si inseriscono nel GIS. Il dimensionamento dei simboli grafici ad una scala di riferimento per la quale quella determinata mappa e' valida ha lo stesso identico significato, e quindi importanza, della cura che si pone nella vettorializzazione, ovvero nella quantizzazione dei dati. Quando Furieri dice "preoccupatevi di acquisire bene i dati, e tutto il resto verra' da solo" dice una cosa giusta, ma e' un concetto molto teorico, perche' cosa significa "acquisire BENE i dati"? L'unico modo per acquisire BENE i dati sarebbe di acquisirli in scala 1:1, in continuo, e poi andare giu' di thinning per scale successivamente piu' ridotte. Ma poiche' ovviamente cio' non e' possibile, e si devono fare sempre delle approssimazioni, si deve tener conto fin dall'inizio della precisione di cui necessiteremo. Questo si riverbera nella scala di acquisizione e successivamente di rappresentazione, o, al contrario, e' la scala di rappresentazione richiesta (per motivi funzionali, ad esempio, si sceglie di lavorare al 10.000 piuttosto che al 5.000 piuttosto che al 25.000, in geologia, per determinati scopi o approcci diversi) che determinera' la scala di acquisizione del dato e quindi la validita' dello stesso. Ragionare solo di spessori in pixel e' sicuramente molto limitante e fuorviante, e deriva da un approccio al GIS che ha bypassato la cartografia intesa come output di fruizione del dato cosi' come puo' essere una query del db, considerandola invece solo come un elemento del tutto ornamentale e non intrinseco al GIS stesso. > Mi pare invece di capire dal tuo intervento che GeoServer come capacita' grafica e' inferiore a entrambi. > > Cosa centra tutto questo con la dipendenza dal software proprietario ? > > Centra nella misura in cui per riprodurre una tale grafia si deve abbandonare il GIS propriamente detto e rivolgersi al mondo CAD. Non voglio fare il pedante, ma il GIS "propriamente detto" INCLUDE la vestizione cartografica e l'output. Ribadisco quanto ho gia' avuto modo di dire: molti (di estrazione prettamente informatica, mi viene da agiungere... ma non e' obbligatorio) pensando che il GIS propriamente detto si occupi solo dei dati e della loro gestione informatica, intesa come database e topologia, ma se si prescinde dalla RAPPRESENTAZIONE con tutto cio' che questo comporta ci si accorge a un certo punto che ci si e' scordati un pezzo per strada... Comunque le tue considerazioni sono molto interessanti: sono di fatto una presa di coscienza di un aspetto non preso in considerazione prima. > > Fino ad ora pensavo che questa esigenza di graficismo spinto fosse una esigenza specifica dei cartografi. > Quindi una nicchia di persone . Ehm. Non so perche' i cartografi devono essere considerati una nicchia di persone..... :) Allo stesso modo potrei definire i tecnici GIS. Un geologo E' anche un cartografo (di cartografia geologica), come puo' essere un informatico GIS e altro. Non e' che i cartografi sono solo quelli che mettono tutte le barbette alle linee di scarpata :) > Invece mi pare di capire dal tuo e da interventi precedenti che anche i geologi hanno questa esigenza di riprodurre carte con segni e regole di tracciatura molto rigorose, > dove li spessori e le regole di tratteggio imperano e la fanno da padrona. Si, vero, noi geologi per la natura della nostra disciplina iniziamo a fare carte il primo anno, con pastelli, gomme pane, chine eccetera. Ci e' proprio richiesto negli esami. Ma allo stesso modo potrei citare gli architetti, gli urbanisti, i forestali.... > > Questo mi spinge a pensare che come i cartografi, anche i geologi per riprodurre una carta corretta secondo certe regole grafiche, > dovrebbero fare ricorso a mezzi CAD. > A meno di non fare cose approssimate e probabilmente sempre contestabili . > > Ma non ho mai visto un geologo lavorare con un sistema Cad (commerciale o no). Orpo! Ho visto centinaia di geologi lavorare con Autocad, ho realizzato in prima persona un set di campiture Autocad (sia maledetto nei secoli quel software orripilante e demenziale) per una serie di lavori per Ferrovie dello Stato e Italferr, CAVET, Alta velocita'... mi sono dovuto smazzare con i CTB desiderando contestualmente il suicidio o che qualcuno mi finisse con un colpo in fronte... Ho visto anche geologi lavorare con tutti i possibili software tra il CAD e l'impaginazione grafica, da Corel Draw a Illustrator a Canvas, da Microstation (usato in Facolta' a Bologna nel laboratorio del prof. Farabegoli!) a VectorWorks a chi piu' ne ha piu' ne metta.... Ho visto i raggi B balenare nel buio vicino alle porte di Tannhauser... :-) Ovvio che nel momento in cui dai in mano un software per la gestione GIS a un geologo o a un urbanista, una delle prime cose di cui si preoccupa, data per scontata la validita' della base dati alla scala di riferimento, e' di avere a disposizione un tool che permetta di rappresentare i dati in maniera consequenziale al tipo di analisi ed alle considerazioni che sono state fatte nell'acquisizione degli stessi. Ciao! Marco GEOgrafica _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
|
|
In reply to this post by GEOgrafica
Il giorno 11 aprile 2011 11:18, GEOgrafica <[hidden email]> ha scritto:
Un lavoro a cui ho partecipato recentemente progettazione del modello dati e metodi di generalizzazione da CTR al 5.000 per la produzione delle nuove CTR 10.000 e 25.000 di una Regione ci ha occupati per un anno e mezzo, e la gran parte del tempo passato a modellizzare il db è stato dedicato a definire attributi e relazioni per poter gestire la corretta visualizzazione e vestizione degli elementi alle varie scale. Una parte del db è dedicata completamente alla simbologia.
In azienda crediamo che la parte DB poteva essere fatta benissimo in ambiente open. Anche se la gestione di modelli topologici che trovo in Oracle non li ritrovo in Postgis, avremmo potuto ovviare in qualche modo.
Per quanto riguarda la produzione cartografica (che è il prodotto poi realmente usato dalla Regione) invece non avevamo alternative da proporre, rispetto a quanto disponibile negli strumenti proprietari già in uso. Insomma, ce n'è di strada da fare, e con il contributo di ognuno potremmo esplorare anche aree non coperte dagli strumenti già esistenti...
_______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
Re: Re. dipendenza da software proprietario
|
|
In reply to this post by a.furieri
Il giorno 11/apr/2011, alle ore 01.01, [hidden email] ha scritto:
Oppure, piu' semplicemente (e con meno sfiducia verso i miei colleghi), per i tuoi interlocutori era ovvio quello che stavano dicendo, comprese le implicazioni lasciate implicite (e che sono venute fuori in questo thread), e non si sono sforzati molto di spiegartele con la necessaria dovizia di particolari. Per quanto mi riguarda, il discorso non e' marginale e secondario ne' legato ad una ristretta tipologia di utenti: e' invece importantissimo ed intrinseco al GIS, non solo in ambito geologico. La rappresentazione del dato E' PARTE INTEGRANTE del processo di costruzione del GIS, sia nella definizione degli attributi del DB, sia nella costruzione degli strumenti informatici, sia nelle modalita' di fornitura (su supporto cartaceo e su supporto informatico - vedi WebGIS ad esempio). Il problema e' intrinsecamente legato alla SCALA di acquisizione del dato e alla validazione del dato, cosi' come si fa con le topologie o con gli attributi. Questo in realta' avviene... almeno nei confronti degli sviluppatori di software proprietario. I geologi, ad esempio, hanno parlato moltissimo con i tecnici della ditta innominata e di tante altre ditte, per risolvere i loro problemi di graficismo. E hanno trovato un sacco di risposte. A me viene una considerazione maliziosa: le ditte innominate, che volevano VENDERE i loro software e le loro idee, e non farsele copiare dalle ditte concorrenti, si sono smazzate e fatte in quattro per trovare soluzioni proprietarie che accontentassero i loro possibili clienti e permettessero alle loro ditte di colonizzare quella nicchia di mercato. Forse (dico forse) fino ad oggi nel mondo OpenSource l'argomento non e' stato preso molto in considerazione, e forse (dico forse, e forse e' questa e' proprio una malignita') uno dei motivi e' stato che nel mondo OpenSource gli informatici si sono molto preoccupati dei db e dei software per gestirli, sottovalutando o sminuendo certi temi che, non nascendo da loro diretta necessita', venivano considerati "poco importanti". I tecnici non informatici, volendo saltare subito all'utilizzo e non smazzarsi troppo con informatici che non capivano o non davano peso a quello che veniva richiesto ("le belle cartine colorate che non servono a un tubo", come diceva l'ingegnere programmatore da me citato in un post precedente), molte volte hanno preferito rivolgersi a sw proprietari con tool gia' pronti, con commerciali che arrivavano come le mosche sul miele, fregandosi le mani a-la-Bruno-Vespa..... Seguo n mailing list su sw open (a partire da OpenSceneGraph) e non e' certo raro trovarmi a discutere con programmatori che non capiscono quello che sto chiedendo o sul quale sto ragionando, e che liquidano i miei discorsi con "perche' dovrei perderci tempo? a cosa serve? non serva a niente... quello che serve veramente e' A, B, C....". E' difficile arrivare ad una crescita della comunita' open se l'approccio di alcuni e' ottuso. Quindi, informatici, scendiamo (mi ci metto dentro per primo io) dal pero, e ascoltiamo le esigenze altrui! :) Non tanto per fare contenti questi pazzoidi di geologi, ma per capire sempre meglio quello che stiamo facendo e farlo al meglio! Ciao Marco GEOgrafica _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
|
|
Il giorno lun, 11/04/2011 alle 11.54 +0200, GEOgrafica ha scritto:
> Seguo n mailing list su sw open (a partire da OpenSceneGraph) e non e' > certo raro trovarmi a discutere con programmatori che non capiscono > quello che sto chiedendo o sul quale sto ragionando, e che liquidano i > miei discorsi con "perche' dovrei perderci tempo? a cosa serve? non > serva a niente... quello che serve veramente e' A, B, C....". E' > difficile arrivare ad una crescita della comunita' open se l'approccio > di alcuni e' ottuso. Non e' esattamente cosi': se non ci sono quelle funzioni e' perche' nessuno ci ha ancora investito. Se gli sviluppatori stessero dietro alle *richieste*, non arriverebbero da nessuna parte. Le richieste che vengono ascoltate ed esaudite sono soprattutto quelle che: - risultano interessanti per gli sviluppatori, secondo le loro inclinazioni personali - sono sponsorizzate da qualcuno a cui servono. Dare degli ottusi agli sviluppatori, scusa, ma e' quasi un ossimoro: in generale, sono la classe di persone piu' intelligente e brillante in cui mi sia imbattuto, in vita mia. Saluti. -- http://www.faunalia.it/pc _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
|
|
Il giorno 11 aprile 2011 12:00, Paolo Cavallini <[hidden email]> ha scritto: Il giorno lun, 11/04/2011 alle 11.54 +0200, GEOgrafica ha scritto: Concordo sulla prima parte. Non possiamo aspettarci che i core developers possano coprire "gratuitamente" tutte le richieste. Un primo contributo, anche se non monetario, potrebbe essere raccogliere le esigenze cartografiche con cui ci siamo confrontati nella nostra esperienza lavorativa. Richiede tempo, lo so, ma questo può essere un contributo economico, visto che il tempo è denaro!
Sulle priorità di sviluppo... bhè, spero che l'ordine non sia quello che hai dato. Un informatico che non si interessi realmente dei problemi di una manifattura non potrà mai fare un buon gestionale. Un informatico che si occupa di GIS, non dovrebbe disinteressarsi di quanto discusso finora... Almeno, non dovrebbe farlo se il suo interesse è fare un software GIS tendenzialmente completo e competitivo rispetto ad altre soluzioni.
Non so se nel comitato di QGis, ad es., sono presenti cartografi (in senso lato). Se mancano, sarebbe una presenza importante da colmare, visto che è lo stesso comitato che decide come investire le donazioni e le sponsorizzazioni.
giovanni
_______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
Re: Re. dipendenza da software proprietario
|
|
In reply to this post by pcav
Il giorno 11/apr/2011, alle ore 12.00, Paolo Cavallini ha scritto: > Il giorno lun, 11/04/2011 alle 11.54 +0200, GEOgrafica ha scritto: > >> Seguo n mailing list su sw open (a partire da OpenSceneGraph) e non e' >> certo raro trovarmi a discutere con programmatori che non capiscono >> quello che sto chiedendo o sul quale sto ragionando, e che liquidano i >> miei discorsi con "perche' dovrei perderci tempo? a cosa serve? non >> serva a niente... quello che serve veramente e' A, B, C....". E' >> difficile arrivare ad una crescita della comunita' open se l'approccio >> di alcuni e' ottuso. > > Non e' esattamente cosi': se non ci sono quelle funzioni e' perche' > nessuno ci ha ancora investito. Se gli sviluppatori stessero dietro alle > *richieste*, non arriverebbero da nessuna parte. > Le richieste che > vengono ascoltate ed esaudite sono soprattutto quelle che: > - risultano interessanti per gli sviluppatori, secondo le loro > inclinazioni personali > - sono sponsorizzate da qualcuno a cui servono. A me e' anche capitato che di aver sponsorizzato di tasca mia uno sviluppatore per implementare una funzione che non ero in grado di fare da solo, per mia non conoscenza di un determinato linguaggio, e trovarmi un prodotto con funzioni non richieste e altre mancanti, e vedermi fatturare le funzioni non richieste e successivamente le funzioni mancanti, fatte obtorto collo e con un continuo lamento perche' "non avevano senso". Alla fine mi sono anche visto le mie funzioni, pagate con i miei soldi, inserite nella distro open del tool del quale avevo chiesto la personalizzazione, il tutto senza il mio beneplacito. Permettimi di essere poco ottimista rispetto a un certo tipo di approccio. > Dare degli ottusi agli sviluppatori, scusa, ma e' quasi un ossimoro: Tua opinione, io non la condivido. Comunque, io non ho dato degli ottusi alla "categoria" degli sviluppatori, ho parlato di "alcuni" sviluppatori che hanno un atteggiamento ottuso. Posso dire per esperienza personale che mi e' capitato di avere a che fare con sviluppatori ottusi che continuavano a bollare come inutili le cose che a loro non interessavano, o che ritenevano "fatte male, poco efficienti", e questo perche' faticavano a staccarsi da "cio' che risultava a loro interessante per la loro inclinazione personale". Il che potrebbe essere accettabile - ma non certo sintomo di intelligenza - finche' si rimane nell'ambito di uno sviluppo condiviso, mentre non e' piu' accettabile se si sta lavorando su commissione. Ripeto, e' una esperienza personale, e come la mia te ne potrei citare altre di colleghi. Non sta bene parlarne in discussioni pubbliche, non si tratta di colleghi italiani, ma stiamo parlando di persone in carne e ossa con nome e cognome. > in > generale, sono la classe di persone piu' intelligente e brillante in cui > mi sia imbattuto, in vita mia. Si puo' essere intelligentissimi, brillanti, eppure autoreferenziali e ottusi. La storia della matematica, ad esempio, e' piena di esempi. Per chiarire meglio quanto detto piu' sopra, nella mia esperienza specifica non mi riferisco a nessuno dei presenti sulla ML GFOSS, sia ben chiaro. Nel mio caso io parlo di esperienze su progetti internazionali legati all'ambito della visualizzazione 3d. Casi conclamati che hanno portato a fork, fratture insanabili, citazioni in tribunale eccetera eccetera. Persone brillantissime e intelligentissime, propugnatrici della filosofia Open, ognuna pero' con la PROPRIA filosofia Open, diversa da quella del contendente, che hanno perso un sacco di energie e di tempo a litigare fra loro. Purtroppo siamo uomini e per nostra natura fallaci. Ciao Marco > Saluti. > -- > http://www.faunalia.it/pc > _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
|
|
In reply to this post by GEOgrafica
On Mon, 11 Apr 2011 11:54:13 +0200, GEOgrafica wrote
> Questo in realta' avviene... almeno nei confronti degli sviluppatori di software proprietario. > I geologi, ad esempio, hanno parlato moltissimo con i tecnici della ditta innominata e di > tante altre ditte, per risolvere i loro problemi di graficismo. > E hanno trovato un sacco di risposte. > A me viene una considerazione maliziosa: le ditte innominate, che volevano VENDERE i loro > software e le loro idee, e non farsele copiare dalle ditte concorrenti, si sono smazzate e fatte > in quattro per trovare soluzioni proprietarie che accontentassero i loro possibili clienti e > permettessero alle loro ditte di colonizzare quella nicchia di mercato. > Esatto: è proprio così ... chi lavora per biechi scopi di profitto ha evidentemente tutte le giuste motivazioni per andare in giro a sondare i desideri degli utenti: tanto poi si farà pagare profumatamente :-) Ma perchè mai uno sviluppatore open source dovrebbe andarsene spontaneamente al giro ad elemosinare informazioni da interlocutori magari reticenti e/o poco motivati a collaborare ??? Per avere poi la "soddisfazione" di potere lavorare (del tutto gratuitamente) per qualche mese su un problema rognoso e complicato ? Gli sviluppatori open source saranno anche un po' pazzerelli, ma di sicuro non sono masochisti fino a questo punto :D > Forse (dico forse) fino ad oggi nel mondo OpenSource l'argomento non e' stato preso > molto in considerazione, e forse (dico forse, e forse e' questa e' proprio una malignita') > uno dei motivi e' stato che nel mondo OpenSource gli informatici si sono molto preoccupati > dei db e dei software per gestirli, sottovalutando o sminuendo certi temi che, non nascendo > da loro diretta necessita', venivano considerati "poco importanti". > Non c'è nessuna malignità: è proprio esattamente così Se posso scegliere come investire il mio tempo, ovviamente preferisco muovermi la dove esiste una teoria solida, una abbondante letteratura liberamente accessibile, e magari uno standard formale (ISO, OGC, W3C etc etc). E con questo non è che considero il resto "poco importante": mi limito semplicemente ad amministrare le (scarsissime) energie a disposizione nel modo più razionale e produttivo per tutti, concentando l'attenzione sui fondamentali assolutamente prioritari. e che i db etc etc siano indispensabili credo sia fuor di discussione, no ? > E' difficile arrivare ad una crescita della comunita' open se l'approccio di alcuni e' ottuso. > Santissime parole, che faccio mie al 101% Valgono per gli sviluppatori, ma valgono ovviamente anche per gli utenti. Pretendere di stare neutralmente sospesi a metà strada tra sw libero e sw proprietario "perchè voi siete talebani e noi siamo gente con i piedi per terra" ovviamente non aiuta affatto a crescere. Per crescere serve che anche gli utenti mettano in rete le proprie competenze e conoscenze, investano tempo e fatica per spiegare per bene e con calma le proprie esigenze agli "ottusi" sviluppatori, perdano tempo (tanto tempo) per fare testing e debugging etc etc E magari (come ricordava Paolo Cavallini) servono anche utenti disposti ad investire qualche soldino per supportare il ciclo di sviluppo :D Se nessuno zappa il campo, poi non è certo lecito lamentarsi perchè manca il raccolto !!! ciao Sandro _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
Re: Re. dipendenza da software proprietario
|
|
Il giorno 11/apr/2011, alle ore 12.39, [hidden email] ha scritto:
La discussione qui in ML e' nata dal fatto che "la vestizione grafica" era stata definita, attraverso i vari messaggi, "poco importante/interessante/impegnativa". Sul resto, ti capisco e concordo abbastanza. Abbastanza perche' comunque se mi muovo sempre nella sicurezza della mia "terra cognita" non scopriro' mai l'America. Obviously. Spero che prima o poi arriveremo in maniera condivisa anche a definire indispensabili e fondamentali le implicazioni legate alla rappresentazione grafica e alla comunicazione dei dati. E non solo un viaggio mentale di quegli zuzzerelloni dei geologi che giocano con le Ecoline e i pastelli Giotto. :) Si puo' anche stare neutralmente a meta' strada tra sw libero e proprietario con motivazioni meno ideologiche :) Yes, hai ragione, ma vedi mia risposta a Cavallini come report di brutta esperienza nel settore dell'investimento con sviluppatori Open. E' lecito lamentarsi perche' il bracciante lavora male, pero', o se mi zappa solo le patate perche' a lui le bietole non gli piacciono! Ciao Marco GEOgrafica _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
|
|
Il giorno lun, 11/04/2011 alle 13.05 +0200, GEOgrafica ha scritto:
> E' lecito lamentarsi perche' il bracciante lavora male, pero', o se mi > zappa solo le patate perche' a lui le bietole non gli piacciono! E' lecito solo se lo paghi tu. -- http://www.faunalia.it/pc _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
|
|
In reply to this post by GEOgrafica
On Mon, 11 Apr 2011 13:05:58 +0200, GEOgrafica wrote
> Il giorno 11/apr/2011, alle ore 12.39, [hidden email] ha scritto: >> Se nessuno zappa il campo, poi non è certo lecito lamentarsi >> perchè manca il raccolto !!! > > E' lecito lamentarsi perche' il bracciante lavora male, pero', > o se mi zappa solo le patate perche' a lui le bietole non > gli piacciono! > mica poi tanto lecito IMHO; la regola base delle moderne democrazie occidentali dice: No taxation without representation ma vale ovviamente anche il reciproco: No representation without taxation :-P ed ovviamente per "taxation" non intendo necessariamente vile denaro, ma anche e soprattutto collaborazione e convinta partecipazione, e prima ancora sentirsi membri attivi e consapevoli di una collettività solidale. ciao Sandro _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
Re: Re. dipendenza da software proprietario
|
|
In reply to this post by pcav
Il giorno 11/apr/2011, alle ore 13.20, Paolo Cavallini ha scritto: > Il giorno lun, 11/04/2011 alle 13.05 +0200, GEOgrafica ha scritto: >> E' lecito lamentarsi perche' il bracciante lavora male, pero', o se mi >> zappa solo le patate perche' a lui le bietole non gli piacciono! > > E' lecito solo se lo paghi tu. Vero. Di questo sto parlando, esempio concreto di persona che, pagata da me per zappare tutto, zappava solo le patate perche' il resto per lui non era importante. Bravissimo e intelligentissimo programmatore OTTUSO, oltre che poco serio, visto che si e' preso i miei soldi e non ha fatto quello per cui era stato assunto. Ciao Marco _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 502 iscritti all'11.2.2011 |
«
Return to Gfoss -- Geographic Free and Open Source Software - Italian mailing list
|
1 view|%1 views
| Free forum by Nabble | Edit this page |