[Gfoss] dipendenza da software proprietario

[a.furieri a lqt.it]

La discussione inizia a farsi interessante: a mia personale 
memoria, forse è la prima volta in cui si esce dal generico 
blah blah di posizione ideologicamente contrapposte e 
si entra invece nello specifico di casi d'uso concreti.

---

faccio un piccolo passo indietro, e ritorno al post originale 
di Luca Maldolesi:

> In soprintendenza archeologica in Emilia Romagna, 
> hanno iniziato a valutare l'utilizzo del GIS (alleluja), 
> ma mi hanno fatto presente, e in parte non a torto, 
> che se tutti i comuni e le province stanno usando prodotti 
> ESLI, sarebbe bene che anche loro si allineassero 
>

eh no Luca: questo ragionamento è decisamente inaccettabile 
e perverso. 
Gli standard aperti esistono proprio per garantire 
che sistemi eterogenei possano liberamente scambiarsi 
i dati, a prescindere totalmente dall'uso di determinati 
prodotti sw

Il fatto che tutti gli altri Enti usano il prodotto X 
non è e non può essere giustificazione sufficiente 
per costringere anche te a scegliere il medesimo 
prodotto: evidentemente questo tipo di ragionamento 
fa acqua da tutte le parti, e non resisterebbe 
certo ad un eventuale ricorso legale.

> però il comune mi chiede di impacchettare il tutto 
> dentro file .mxd e con vestizioni .lyr 
>

e questo chiarisce definitivamente lo scenario (almeno 
mi pare): la carta archeologica viene prodotta dalla 
sopraintendenza, che poi cerca di passarla in formato 
SHP al comune per opportuna conoscenza.

ma il comune a questo punto obbietta che se non vengono 
forniti a corredo anche i files .mxd e .lyr loro non 
sono in grado di utilizzare la carta archeologica.

Domando: a voi pare un ragionamento tecnicamente motivato 
ed accettabile ? 
vi risulta che siano questi i normali criteri che si 
seguono abitualmente quando ci si scambiano dati tra 
amministrazioni differenti ? 
A me personalmente risulta tutt'altro ... ma magari 
sono io che mi sbaglio :-)

---------

passo ora al post di Giovanni Allegri:

> Ritengo che un punto di forza di un progetto .mxd stia 
> nel fatto che la complessità cartografica offerta da 
> certi strumenti, non la si trova in altri liberi. 
> Sandro, permettimi di dire che l'aspetto cartografico, 
> la resa estetica di una carta, non è un accessorio in più, 
> di cui si può anche fare a meno. 
>

risposta A {scherzosa e per nulla seria}: 
----------------------------------------- 
grazie Giovanni, finalmente mi hai fatto capire come mai 
ho dovuto passare assai spesso lunghe notti insonni cercando 
di rattoppare affannosamente dati vector altamente tossico-nocivi 
(pieni zeppi di geometrie illegali e malformate). 
e/o cercando di ricavare un qualche succo logico utilizzabile 
dall'elaborazione di attributi informativi incompleti, 
omissivi, malformattati e logicamente inconsistenti ed 
auto-contraddittori.

Scusami, non avevo capito che la cosa più importante di una 
cartografia è che deve essere "esteticamente bella a vedersi": 
evidentemente pretendere che sia anche geometricamemte 
coerente e logicamente consistente è solo una mia fisima 
personale (ma io non sono un cartografo, dopotutto) :D


risposta B {serissima}: 
----------------------- 
obiezione in parte giustificata ed accettabile: definire 
una vestizione ottimizzata per un progetto complesso con 
un centinaio di layers non è certo una passeggiata. 
è un processo lungo ed assorbe un bel po' di tempo, 
quindi merita sicuramente tutelare l'investimento 
sul lungo periodo.

ma proprio per questo non mi pare per nulla saggio 
spendere soldi (del contribuente) per ottenere alla 
fine qualcosa che puoi utilizzare solo con un ben 
determinato prodotto/versione (ho trovato del tutto 
illuminante il post di Andrea Peri in merito).

esiste uno standard aperto e del tutto neutro per gestire 
questi aspetti: SLD [styled layer descriptor]. 
magari non proprio tutti lo supportano (... per ora ...): 
ma sicuramente è il miglior candidato da prendere in 
serissima considerazione per arrivare a rendere del tutto 
trasparenti e neutri anche gli aspetti legati agli stili 
grafici.

giusto come termine di confronto: ai tempi ormai lontani 
della "guerra dei browsers" la pietra dello scandalo 
furono proprio gli stili grafici 'sofisticati'. 
M$ lanciò ad arte una raffica di pseudo-tecnologie che 
supportavano ad hoc 'effetti speciali' mirabolanti 
(di scarsa sostanza ma di grande impatto 'visual'), 
e riuscì così a mettere fuori mercato Netscape.

Poi sono arrivati JavaScript+DOM, HTML-4 ed i CSS; 
conclusione: oggi il browser che detiene il record 
mondiale di incompatibilità con tutti gli standard 
internazionali del W3C è proprio MSIE. 
e la stessa M$ ha via via dichiarato obsolete, deprecate 
e non più supportate un sacco di quelle tecnologie che 
tanto aveva strombazzato all'epoca (vedi DCOM etc). 
  
chi è stato così tanto sprovveduto da legarsi allora mani 
e piedi alle offerte 'avvelenate' di M$ ora deve sudare 
(e spendere) per liberarsi da tutte le scorie tossiche 
e rientrare finalmente nella normalità.

ma in fondo questa triste storia del lock-in avvelenato 
che ti inchioda pretestuosamente a tecnologie proprietarie 
in chiave esclusivamente spilla-soldi la conosciamo tutti 
a memoria fin dai remoti anni '60 (all'epoca dei mainframe 
IBM): nulla di nuovo sotto il sole ... 
semplicemente, stupisce che ancora così tanta gente abbocchi 
ingenuamente ad un amo così vecchio e logoro :-)

ciao Sandro