[Gfoss] Re. dipendenza da software proprietario

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

Il giorno lun, 11/04/2011 alle 10.01 +0200, iacopo@controgeografie.net
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

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! :slight_smile:
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 <cavallini@faunalia.it> ha scritto:

Il giorno lun, 11/04/2011 alle 10.01 +0200, iacopo@controgeografie.net
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
Gfoss@lists.gfoss.it
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/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! :slight_smile:

Ciao
Marco
GEOgrafica

Il giorno 11 aprile 2011 11:18, GEOgrafica <geografica@alice.it> ha scritto:

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.

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…

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! :slight_smile:

Ciao
Marco
GEOgrafica


Iscriviti all’associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@lists.gfoss.it
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