from:"aperi2007"


Buon per oi.

Ma forse non e' stato ben compreso il lavoro di Andre Aime.

Molto importnate per chi vuole sare geosever.


Ancora piu' utile ora che a quando pare stanno ipotizzando che 
qis-server debba diventare un prodotto distinto . Cosa che ovviamente 
creera' ncompatibilit'a con gis desktop e fara' nascere tutta una serie 
di problematiche che i iu' non saranno mai in grado di gestre.


A quel punto avere una via di fug razie al porting degli sld su geoserver.

orra'dire che si puo' usare qgis e pubblicare con geoserver.

Veramente una cosa utile.

Bravo Andrea.


A.

Il 24/09/2016 06:40, Paolo Cavallini ha scritto:

Beh, visto il lavoro di Andrea Aime, già citato, mi pare proprio che i
fatti ti diano, fortunatamente, torto.

Saluti.


___
Gfoss@lists.gfoss.it
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.
807 iscritti al 31/03/2016

Re: [Gfoss] stili incorporati in spatialite


Puo' darsi, ma non lo darei cosi' per scontato.

In realta' e'una cosa molto potente perche' ha un approcciocompletamente 
differente.


Molte delle cose che qgis fa , li' sono implicite nella modalita' 
descrittiva della vestizione.
Il fatto di descriverla per singola feature (singolo record) permette di 
avere

una parcellizzazione assoluta.
Cosa che qgis non ha perche' al massimo lavora per categorie oppure 
applica dei valori presi da un dataset.


Il rule-rendering di qgis , ad esempio

nella featurestyle E' IMPLICITO.

Sia per le vestizioni che per i testi. E non e' poco per niente.

Perche' semplicemente vestendo singolarmente ogni feature, potrei in 
teoria sbizzarrirmi a vestire un milione di records ognuno  con uno 
stile differente.


Cosa che con qgis non potrei mai fare.

QGIS propone il succedaneo della vestizione tramite campo dello 
shapefile, ma appunto e' un succedaneo.


Perche' obbliga comunque ad avere uno stle comune tra tuttele feature e 
permette di cambiare size, colori e testi.


Ma non passare da un stile di un certo tipo a uno di tipo completamente 
differente.


Poi , come tutti gli standards, ovviamente dipende dallambiente di 
implementazione, ovvero dal mapserver in questo caso, oppure l'ambiente 
is che lo impiega.


Credo che sia roba supportata da Bentley.

Lo standard e' una cosa, l'implementazione e' una altra.


Poi ovviamente , vale lo stesso discorso che dicevi te una volta tanti 
anni fa'.


Non si puo' confrontare un software commerciale che gode di 
moltifinanziamenti con un gfoss che campa di 4 lire.


Vale lo stesso discorso qui.

L'idea della featurestyle e' geniale e gia' ora e' molto potente.

Per il resto confrontare una cosa che e' frutto della mente geniale di 
una o di poche persone e un qgis che ormai e' quasi un framework che 
raccoglie di tutto anche in maniera un po' disordinata non e' possibile.


Chi adotta qgis, lo accetta come e' e non deve poi stupirsi delle sue 
"particolarita' ".


Magari su 1 persone che usano qgis, solo 1 potrebbe essere 
interessata alla featurestyle.

E' giusto che sappia che esiste.
Poi se preferisce usare qgis e'una sua libera scelta.
In fondo questa e' la liberta' del gfoss.
Permettere a chunque di usare quelo che meglio gli torna per il suo lavoro.

A.


Il 24/09/2016 06:40, Paolo Cavallini ha scritto:

Purtroppo quelle vestizioni coprono una parte infinitesima delle
possibilità, sempre in espansione, di QGIS, che tutti apprezziamo.
Abbiamo fatto un'analisi piuttosto rigorosa, e la strada che proponi
semplicemente non è fattibile.


___
Gfoss@lists.gfoss.it
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.
807 iscritti al 31/03/2016

Re: [Gfoss] stili incorporati in spatialite


Non eì un problemadi standard "efficace".

Ma piuttosto un problema di fare le cose sempre nel solito modo.

Quello che lamenta salvador non e' di avere uno standard di vestizione 
che ia comune a tanti GIS differenti,


m piutttosto che le vestizioni QML di qgis su spatialite quando qgi le 
salva su spatialite non sa le api standard e cosi' facendo non sono 
gestibili


da gli ambienti esterni a spatialite.


Questo non centra molto con luno standard di vestizione.

Il problema lo avreste pari pari anche se qgis fosse compatibile al 100% 
con le sld di geoserver.
Il problema in altri termini e' che spatialite prevede di archviiare 
files di vestizioni (qualunque esse siano e per qualsiasi programma gis 
essi siano) in una cassetta tonda. QGIS invee le salva in una cassetta 
quadrata.


Amen.
A.

Il 24/09/2016 06:40, Paolo Cavallini ha scritto:

Il problema, come già sottolineato, è che standard efficaci per la
vestizione avanzata semplicemente non esistono. Altrimenti li avremmo
usati, ovviamente.
Credo che gli sviluppatori di QGIS siano persone sufficientemente
intelligenti per capire l'utilità degli standard.


___
Gfoss@lists.gfoss.it
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.
807 iscritti al 31/03/2016

Re: [Gfoss] stili incorporati in spatialite


In qgis ci sono 3 modi di caricare i dati spatialite:

il provider di furieri, l'impiego di ogr e il db manager.

A seconda di quale si usa si hanno implicazioni diverse.


A.

Il 24/09/2016 06:40, Paolo Cavallini ha scritto:

Smentisco*ufficialmente*  questa affermazione. QGIS non è una persona,
quindi non ha né amore né odio. Semplicemente, è un ambiente aperto, in
cui chiunque porti buon codice è ben accetto.


___
Gfoss@lists.gfoss.it
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.
807 iscritti al 31/03/2016

Re: [Gfoss] Importazione DXF areale in QGis

2016-05-07 Per discussione aperi2007

Potrei sbagliamri, ma mi pare di ricordare che l'importatore DXF di 
spatialite e' istruito per


convertire in poligoni le polilinee dichiarate CHIUSE.

Potresti provare con la spatialite-GUI che e' abbastanza sempice da usare.
Se operi su windows trovi una versione gia' compilata sul sito di 
spatialite.

Con essa importi il DXF in uno spatialite.

E se la polilinea e' dichiarata chiusa dovrebbe essere trasformata in 
poligono.


Lo spatialite te lo legge qgis direttamente, ma se ti interessa lo 
shapefile puoi sempre da spatialite esportare in shapefile.



A.

Il 07/05/2016 21:06, Lorenzo Luisi ha scritto:

Salve a tutti,
vorrei esporre una situazione che non riesco a risolvere.
Ho un file dxf di polilinee che risultano chiuse e cerco di importarlo in
QGis, ma mi ritrovo con degli elementi lineari!
Provo anche con il plugin DXF2SHP converter (indico che voglio poligoni),
ma mi viene evidenziato un errore (creato un dump relativo al blocco) e mi
chiude QGis.

Qualcuno può darmi degli hint per risolvere la questione?
Grazie,
Lorenzo Luisi




___
Gfoss@lists.gfoss.it
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.
807 iscritti al 31/03/2016


___
Gfoss@lists.gfoss.it
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.
807 iscritti al 31/03/2016

Re: [Gfoss] Informativa su un comportamento anomalodi qgis

2016-04-24 Per discussione aperi2007


E' una prova che va sicuramente fatto.
Personalmente non posso farla subitissimo perche' attualmente sono 
posizionato su postgres 9.3.1 e postgis 2.1.1 e con una gdal/ogr troppo 
vecchia.


Sicuramente occorre usare le ultime versioni di questi due prodotti, ma 
serve anche una versione ultimo grido di gdal/ogr visto che in essa vi 
sara' la patch di Even Rouault citata nel ticket di qgis.


Quindi meglio attendere per evitare di fare una prova a vuoto.
Appena tutti i mattoncini saranno al loro posto faro' questa prova.

Grazie,

A.


Il 24/04/2016 15:32, Sandro Santilli ha scritto:

Non ho fatto la prova ma ho fatto un po' di ricerche.
Ho scoperto che nel 2008 Paul Ramsey ha aggiunto nella shp2pgsql
il supporto per saltare i record cancellati da un DBF, ma_solo_
quando si caricano DBF senza SHP. Il ticket relativo e' questo:

  https://trac.osgeo.org/postgis/ticket/29

La shapelib gia' supporta la chiamata per determinare se un record
e' cancellato o meno. Quale sia il motivo per cui il record non viene
saltato quando invece e' presente uno SHP mi sfugge, potrebbe non
essercene alcuno.

Se apri un nuovo ticket, aggiungi il riferimento al ticket #29,
in modo da avere un quadro completo del problema.

Grazie !

--strk;


___
Gfoss@lists.gfoss.it
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.
807 iscritti al 31/03/2016

Re: [Gfoss] Il Trentino fa marcia indietro sull'Open Source

2016-04-21 Per discussione aperi2007

Ma guarda un po' che notizia salta fuori !

Grande provincia di Bolzano, sempre
in prima fila e sempre esempio per tutti noi di buone pratiche.
Certo il fatto di essere a statuto speciale aiuta un pochino visto che
hanno un budget che altre province e regioni se lo sognano.
Ma e' lo stesso budget che aveva anche prima quando era l'eroe del gfoss
e quindi non e' la spiegazione.
Piuttosto se ha fatto certe scelte vuol dire che avra' avuto le sue
buone ragioni tecniche.
Ognuno fa le sue scelte e poi nel bene e nel male sono cavoli sua se le
scelte si rivelano sbagliate e inducono problemi.

Io parlo per me ovviamente.

Il 21/04/2016 22:14, stefano campus ha scritto:

http://altoadige.gelocal.it/bolzano/cronaca/2016/04/19/news/no-al-software-libero-la-provincia-brucia-almeno-600mila-euro-1.13328439?refresh_ce

https://joinup.ec.europa.eu/community/osor/news/south-tyrol-makes-u-turn-drops-libreoffice-project

--
View this message in context:
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Il-Trentino-fa-marcia-indietro-sull-Open-Source-tp7595782.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian
mailing list mailing list archive at Nabble.com.
___
Gfoss@lists.gfoss.it
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.
807 iscritti al 31/03/2016

Re: [Gfoss] GDAL 2

2016-02-19 Per discussione aperi2007

oops, solo dopo mi sono accorto che avevi gia' segnalato la 
disponibilita' del nuovo epsg italico.


Sorry for the noise.

A.


Il 19/02/2016 20:45, aperi2007 ha scritto:

Grazie della segnalazione Stefano.

Tra le miglirie di gdal 2,0 vi sarebbe anche il db epsg 8.5 che e' 
quello contenente i nuovi Sistemi di Riferimento Italiani nazionali 
EPSG:6707-8 etc...


Sai se vi e' l'intenzione di QGIS di passare anche a questo nuovo db 
epsg e quindi supportare i nuovi SR italici ?


Grazie,

A.

Il 19/02/2016 15:13, stefano campus ha scritto:
ciao, approfitto dell'adozione  di gdal 2 da parte di qgis per 
segnalarvi

l'elenco delle migliorie:

http://www.osgeo.org/node/1591

s.



--
View this message in context: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/GDAL-2-tp7595506.html
Sent from the Gfoss -- Geographic Free and Open Source Software - 
Italian mailing list mailing list archive at Nabble.com.

___
Gfoss@lists.gfoss.it
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.

808 iscritti al 30.01.2015




___
Gfoss@lists.gfoss.it
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.
808 iscritti al 30.01.2015

Re: [Gfoss] GDAL 2

2016-02-19 Per discussione aperi2007


Grazie della segnalazione Stefano.

Tra le miglirie di gdal 2,0 vi sarebbe anche il db epsg 8.5 che e' 
quello contenente i nuovi Sistemi di Riferimento Italiani nazionali 
EPSG:6707-8 etc...


Sai se vi e' l'intenzione di QGIS di passare anche a questo nuovo db 
epsg e quindi supportare i nuovi SR italici ?


Grazie,

A.

Il 19/02/2016 15:13, stefano campus ha scritto:

ciao, approfitto dell'adozione  di gdal 2 da parte di qgis per segnalarvi
l'elenco delle migliorie:

http://www.osgeo.org/node/1591

s.



--
View this message in context: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/GDAL-2-tp7595506.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian 
mailing list mailing list archive at Nabble.com.
___
Gfoss@lists.gfoss.it
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.
808 iscritti al 30.01.2015


___
Gfoss@lists.gfoss.it
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.
808 iscritti al 30.01.2015

Re: [Gfoss] QGIS - Duplica Layer fa ... miracoli !

2015-11-24 Per discussione aperi2007


Due sono le possibili risposte a una domanda:

La prima e' si'.
La risposta "si" espone poi al rischio di una lunga e tediosa 
discussione su come si fa'.


La seconda possibile risposta e' "no".
La risposta "no" e' molto piu' pratica perche tronca il discorso li'.

Venendo alla tua domanda:
La risposta e' "no".

A.


Il 24/11/2015 16:22, FABIO ERRICO ha scritto:

Ho una foto aerea e un SOLO layer poligonale:
devo impaginare una cartina ... che deve fare la sua figura.
Voglio che i riempimenti dei poligoni si vedano in trasparenza sotto 
la foto,
mentre i contorni dei poligoni si vedano sopra la foto, non in 
trasparenza, belli nitidi.

Posso mai fare ciò SENZA l'ausilio di Duplica layer ?
Fabio Errico




___
Gfoss@lists.gfoss.it
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.
786 iscritti al 30.9.2015


___
Gfoss@lists.gfoss.it
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.
786 iscritti al 30.9.2015

[Gfoss] [OT] - impegnarsi a rispettare il galateo - ex GALATEO delle mailing list (compresa questa) [lungo]

2015-11-15 Per discussione aperi2007


Visto che si sta parlando di galateo.
Cominciamo a usarlo per favore.

Quindi:
Se esci dal discorso principale "Il Galateo."

Per fare digression gratuite e non utili al discoro primrio del galateo, 
come nel tuo caso parlando di argomenti tecnici (bbs e fidonet) utili 
solo a pochi che sanno di cosa stai parlando.
Devi mettere un TAG opportuno alla tua risposta e poiche vai OT (come io 
del resto in questa risposta) devi opportunamente taggare la risposta.


Poi per essre corretto e bravo avresti dovuto mettere almeno un paio di 
link a citazione per permettere a chi legge di riuscire a seguire e 
comrendere cio' che stai dicendo.


Grazie per l'aiuto .

A.


Il 15/11/2015 09:58, Filippo Dal Bosco - ha scritto:

Il giorno Fri, 13 Nov 2015 17:58:55 +0100
Amedeo Fadini  ha scritto:


Questo NON è il luogo dove passare il tempo trolelggiando o scaricare
le proprie frustrazioni. È la principale vetrina che la nostra
comunità mostra al mondo (che capisce l'italiano)

So che Nabble la traveste da forum ma questa  è e resta una MAILING
LIST, con la maggioranza delle persone che riceve i messaggi nella
propria casella di posta. Ergo prima di schiacciare il tasto "invia" e
inondare i PC di tante brave persone è opportuno rileggere 2 volte il
messaggio e chiedersi se risponde agli obbiettivi della lista:

hai perfettamente ragione ma  questo è un fenomeno ( liste -
forum tecnici che diventano luogo di scarico di frustrazioni tipo
bar/osteria) purtroppo molto diffuso.

Negli anni 90 c' erano le BBS  e fidonet. Ogni bit in più costava
scatti telefonici. Quindi la moderazione delle liste era durissima.

Oggi con l' ADSL flat le Mailing List stanno diventando una succursale
di FaceBook.

Quoting corretto ormai sconosciuto

Internet come il filò nell' aia della fattoria



___
Gfoss@lists.gfoss.it
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.
786 iscritti al 30.9.2015

Re: [Gfoss] R: Video introduttivo alla Direttiva INSPIRE

2015-10-17 Per discussione aperi2007

Puoi essere piu' preciso ?

Io non avevo capito che pg dicesse che mancava del software .
I links che riportava PG portavano a pagine dove sono gia' elencati 
softwares Gfoss e non.

Inspire richiede una infrastruttura interoperabile.
L'interoperabilita' e' per definizione una metodica per cui software 
differenti riescono a colloquiare tra di loro.

Grazie ai servizi wms, wfs, wcs, etc... e a formati open.

Io mi aspetterei che in un mondo interoperabile un server wms mpaserver 
riesca a fornire i medesimi servizi di un server wms fatto con geoserver 
ed entrambi riescano a colloquiare in analoga maniera con un qgis.

E di software penserei che ce ne sono gia' abbastanza.

Ma forse ti riferisci a qualche compoenente particolare.

I sensori ?

A.

>INSPIRE è:
>- una direttiva (che definisce i principi)
>- una serie di Regolamenti (che sono norma, in tutti gli Stati Membri)
>- una serie di Technical Guidelines (che non sono binding ma 
specificano "come" implementare la >norma)

Il 18/10/2015 00:58, Alessandro Sarretta ha scritto:

Concordo con la visione di Piergiorgio.
Credo che il percorso verso l'applicazione completa della Direttiva 
INSPIRE sia ancora lungo e che c'è e ci sarà bisogno sicuramente di 
formazione ma forse ancora di più di strumenti (software) che riescano 
a rispondere in modo maturo e stabile alle molte richieste dei 
Regolamenti e delle Technical Guidelines.
In particolare mi pare che non ci sia nulla che riesca ancora a 
gestire pienamente la variabilità e complessità dei modelli dati e su 
questo si dovrà lavorare.

In questo credo che il mondo GFOSS può giocare le sue carte migliori.
Mi sembra di capire che i grandi vendor proprietari non abbiano molto 
interesse a investire su questo, mentre dei piccoli investimenti degli 
enti ad es Regionali sui software GFOSS in ottica INSPIRE potrebbero 
veramente fare da volano.
Servirebbe una qualche forma di coordinamento, forse nazionale, che 
però ancora non vedo...

Ale

On 17/10/2015 15:16, Piergiorgio Cipriano wrote:

INSPIRE è:
- una direttiva (che definisce i principi)
- una serie di Regolamenti (che sono norma, in tutti gli Stati Membri)
- una serie di Technical Guidelines (che non sono binding ma 
specificano "come" implementare la norma)

Andrea, quando scrivo "chi in Europa sta implementando INSPIRE lo fa 
soprattutto con approccio e software GFOSS" ovviamente NON intendo 
che la Direttiva (o i Regolamenti) prevedano l'obbligo di sw OSS.

Ci mancherebbe.
La mia è una semplice constatazione:
- 
https://joinup.ec.europa.eu/community/are3na/news/rating-tools-inspire-implementation-first-step

- http://wiki.osgeo.org/wiki/INSPIRE_tools_inventory

E a scanso di ulteriori equivoci su altre frasi scritte nel messaggio 
precedente (ignoranza):

http://www.treccani.it/vocabolario/ignoranza/
"Con sign. ristretto, l’ignorare determinate cose, per non essersene 
mai occupato o per non averne avuto notizia"

A tal proposito, ne approfitto per segnalare in lista che venerdì 
prossimo (23 ottobre) ISPRA organizza la conferenza finale del 
progetto LINKVIT:

http://www.isprambiente.gov.it/it/events/conferenza-finale-progetto-linkvit-formazione-inspire

... progetto che è proprio focalizzato sulla formazione intorno a 
INSPIRE, con una serie di moduli di training in modalità e-learning 
che forse occorrerebbe conoscere e usare:

http://www.linkvit.eu/moduli-di-apprendimento/

pg

__
Piergiorgio Cipriano
https://twitter.com/PgCipriano

Il giorno 17 ottobre 2015 13:49, aperi2007 <aperi2...@gmail.com 
<mailto:aperi2...@gmail.com>> ha scritto:

L'affermazione

>GFOSS e INSPIRE non sono alternative l'un l'altro.

Giustificata dal fatto che

>Tanto é vero che chi in Europa sta implementando INSPIRE lo fa
soprattutto con approccio e software GFOSS.

Non mi piace troppo.

Non rispecchia cio' che dice la normativa Inspire.

Se uno vuole puo' implementare la normativa Inspire anche con
software commerciale.

Basta che sia interoperabile . Con tutto cio' che esso comporta.
Servizi wms, specifiche OGC, wms, sfw, wcs, csw, etc...

Te non stai dicendo che la Normativa Inspire prevede l'obbligo di
software gfoss, ma il tuo discorso potrebbe far pensare cio'.

A.

Il 17/10/2015 13:40, pg ha scritto:

GFOSS e INSPIRE non sono alternative l'un l'altro.
Tanto é vero che chi in Europa sta implementando INSPIRE lo fa
soprattutto con approccio e software GFOSS.
Il problema italiano é un altro e si chiama ignoranza (in senso
etimologico del termine).

pg

Da: Maurizio Trevisani <mailto:maurizio.trevis...@gmail.com>
Inviato: ‎16/‎10/‎2015 11:29
A: Antonio Falciano <mailto:afalci...@yahoo.it>
Cc: GFOSS. it <mailto:gfoss@lists.gfoss.it>
Oggetto: Re: [Gfoss] Video

Re: [Gfoss] R: Video introduttivo alla Direttiva INSPIRE

2015-10-17 Per discussione aperi2007


L'affermazione

>GFOSS e INSPIRE non sono alternative l'un l'altro.

Giustificata dal fatto che

>Tanto é vero che chi in Europa sta implementando INSPIRE lo fa 
soprattutto con approccio e software GFOSS.


Non mi piace troppo.

Non rispecchia cio' che dice la normativa Inspire.

Se uno vuole puo' implementare la normativa Inspire anche con software 
commerciale.


Basta che sia interoperabile . Con tutto cio' che esso comporta. Servizi 
wms, specifiche OGC, wms, sfw, wcs, csw, etc...


Te non stai dicendo che la Normativa Inspire prevede l'obbligo di 
software gfoss, ma il tuo discorso potrebbe far pensare cio'.


A.

Il 17/10/2015 13:40, pg ha scritto:

GFOSS e INSPIRE non sono alternative l'un l'altro.
Tanto é vero che chi in Europa sta implementando INSPIRE lo fa 
soprattutto con approccio e software GFOSS.
Il problema italiano é un altro e si chiama ignoranza (in senso 
etimologico del termine).


pg

Da: Maurizio Trevisani 
Inviato: ‎16/‎10/‎2015 11:29
A: Antonio Falciano 
Cc: GFOSS. it 
Oggetto: Re: [Gfoss] Video introduttivo alla Direttiva INSPIRE

Attenti : molte normative compreso il recepimento della Direttiva 
Inspire in Italia sono a costo  zero.
Questo è un freno importante che condiziona il processo di 
geo-informatizzazione del nostro paese.
Il Gfoss può risultare strategico,  ma il percorso è in salita, 
sopratutto in questo periodo di crisi.

Ciao,
Maurizio

Il 16/ott/2015 11:06, "Antonio Falciano" > ha scritto:


Il 16/10/2015 07:04, Alessandro Sarretta ha scritto:

Ciao a tutti,
non mi sembra sia passato in lista.
Il JRC alcuni mesi fa ha preparato questo breve video
introduttivo alla
Direttiva INSPIRE:
https://www.youtube.com/watch?v=xew6qI-6wNk

Ne sono venuto a conoscenza tramite un interessante incontro
organizzato
dagli amici Marica Landini e Piergiorgio Cipriano presso la
Regione
Emilia Romagna, e in particolare durante la presentazione di Carlo
Cipolloni.
Aggiungo che, con la scusa dei miei quotidiani spostamenti in
treno, mi
sono preso un po' di tempo per correggere i sottotitoli
automatici di
you tube in inglese, tradurli in italiano, e spedirli al JRC
(che li ha
prontamente caricati, grazie!); così ora nel video ci sono anche i
sottotitoli in italiano... nel caso possa essere utile per
divulgare
ulteriormente .-)


Grazie per la segnalazione, ottimo lavoro! +1
Illustra perfettamente la necessita' e al tempo stesso le opportunita'
dell'armonizzazione dei dati a tutti i livelli e pertanto puo'
rappresentare un valido strumento didattico, non solo per gli studenti
ma anche per burocrati, politici e decision-maker.

ciao
Antonio

-- 
Antonio Falciano

http://www.linkedin.com/in/antoniofalciano
___
Gfoss@lists.gfoss.it 
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.
786 iscritti al 30.9.2015



___
Gfoss@lists.gfoss.it
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.
786 iscritti al 30.9.2015


___
Gfoss@lists.gfoss.it
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.
786 iscritti al 30.9.2015

Re: [Gfoss] algebra (era: Re: compilare QGIS-master su linux)

2015-10-02 Per discussione aperi2007


Puo' darsi.
Ho messo due operazioni differenti per coprire un caso piu' generale.

Si puo' scrivere anche questa:

(A*B)*C <> A*(B*C)

Vale comunque il principio che in aritmetica finita le due versioni possono 
dare risultati differenti.
A seconda dell'ordine in cui si esegue e aseconda dei valori rappresentati da 
A,B e C.

A.



Il 02/10/2015 13:57, giulianc51 ha scritto:

Il giorno Fri, 2 Oct 2015 00:30:00 +0200
aperi2007 <aperi2...@gmail.com> ha scritto:

ciao,
solo un piccolo dettaglio (e ne ho fatto un thread a parte) nella vostra
interessantissima discussione :-)




Erroneamente ho parlato di principio commutativo.
In realta' nell'aritmetica finita viene negato il principio
distributivo e non quello commutativo.
... ma in
ogni caso quello che impiegavo nell'asserzione

(A*B)/C <> A*(B/C)

e' il principio distributivo.

sei sicuro? poiche '/' è l'operazione inversa di '*', siamo in presenza
di una sola legge di composizione (la moltiplicazione), non 2
(tipicamente moltiplicazione e addizione) fra le quali può valere
il principio distributivo;

mi sembra più un problema 'associativo' oppure di un insieme privo
dell'inverso, come ad es. il caso degli interi dove (10*3)/2=15, ma
10*(3/2)=10;

  

A.

ciao,
giuliano
___
Gfoss@lists.gfoss.it
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.
786 iscritti al 30.9.2015


___
Gfoss@lists.gfoss.it
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.
786 iscritti al 30.9.2015

Re: [Gfoss] algebra (era: Re: compilare QGIS-master su linux)

2015-10-02 Per discussione aperi2007


NOn e' un problema dimancanza del'inverso.
Ma un problema diaritmetica finita.

Neicomputer e' piu' facile rappresentare numeri grandi piuttosto che 
numeri piccoli.


Se poi sono molto piccoli allora devi accettare delle approssimazioni.

quando esegui una serie di operazioni , se vuoi inimizzare il problema 
devi sempre privilegiare prima le operazioni che aumentano il valore 
temporaneo e eseguire da ultimo quelle che riducono il valore.

Ovviamente sempre all'intenro della validita' della formula.

Per questo

A = 10.000.000
B = 0.0001
C = 20.000.000

A * (B / C ) = 10.000 * (0.0001 / 20.000.000)

il valore temporaneo e' 0.0001 / 20.000.000  che ti va a finre sotto il 
limite di validita' e quindi diventa approssimato.
e anche se lo moltipli poi per 10.000.000 ormai e' approssimato e non lo 
recuperi piu' al valore esatto.


Se invece te esegui:

A * B come prima operazione ottieni: = 10.000.000 * 0.0001 = 10.000

per cui quando vai a eseguire la successiva:

10.000 / 20.000.000 essendo eseguita con un numerato remaggiore ottieni 
un risultato meno approssimato.


A.

Il 02/10/2015 13:57, giulianc51 ha scritto:

mi sembra più un problema 'associativo' oppure di un insieme privo
dell'inverso, come ad es. il caso degli interi dove (10*3)/2=15, ma
10*(3/2)=10;


___
Gfoss@lists.gfoss.it
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.
786 iscritti al 30.9.2015

Re: [Gfoss] [Spatialite] caricare shapefile in batch

2015-10-02 Per discussione aperi2007

io questo tipo di attivita' la eseguo da dentro la console di 
spatialite, con il comando


.loadshp 

Ma effettua il load di un unico shapefile per cui devi reiterare per 
ogni sp che vuoi caricare.


A.

Il 02/10/2015 13:39, Amedeo Fadini ha scritto:

Salve a tutti,

ma qual'è il modo migliore per caricare una serie di shapefile in un
db spatialite? finora me la sono cavata egregiamente con ogr2ogr da
script Bash o Dos, ho provato ad utilizzarlo anche all'interno di
pyQgis per un plugin che porto avanti nei ritagli di tempo [0], ma
dovrebbe esserci qualcosa di meglio... pyspatialite? Qspatialite?

tenete presente che dovendo caricare e mosaicare la CTR voglio:

- creare la tabella se non esiste, altrimenti aggiungere le feature
- creare l'indice spaziale alla fine
- se il tracciato campi da uno shape all'altro è differente aggiungere
i campi nuovi

forse vale la pena mettersi a fare tutto in python leggendo le
features con pyshp?
Quale strada mi consigliate? Qualche plugin da cui prendere esempio?

amefad

[0] https://gitlab.com/Amefad/importCtr/blob/master/ctr_import_dialog.py
___
Gfoss@lists.gfoss.it
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.
786 iscritti al 30.9.2015


___
Gfoss@lists.gfoss.it
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.
786 iscritti al 30.9.2015

Re: [Gfoss] Linea in comune tra poligoni


quello che te chiedi e' alla base della topologia ISO.
E anche delle coverages esri.

La topologia iso attualmente si trova su postgis e che presto sara' 
disponibile su spatialite.

"Lavori in corso.."

Su qgis secondo me non ci sara' mai perche' sono piu' rivolti 
all'approccio poligon oriented.

Dove la topolgia e' sostanzialmente una snappata sui vertici piu' vicini.

A.


Il 01/10/2015 17:35, Geodrinx ha scritto:

Salve,

dubbio amletico:
Esiste (o non esiste :) in QGIS una funzione che estragga le polilinee in 
comune tra poligoni (corretti dal punto di vista topologico :)
?

Ogni polilinea dovrebbe alla fine mantenere traccia (nella tabella associata) 
dei due poligoni che separava.

Scopo finale sarebbe quello di sapere la lunghezza di ogni linea ottenuta (ma 
questo è un'ovvietà farlo calcolare... :)

Qualcuno sa come ottenere queste linee di separazione tra i poligoni ?  In 
QGIS, of course.

Grazie per qualunque info in merito (attualmente ho un colpo di amnesia :)

Roberto

Inviato da iPhone
___
Gfoss@lists.gfoss.it
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.
786 iscritti al 30.9.2015


___
Gfoss@lists.gfoss.it
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.
786 iscritti al 30.9.2015

Re: [Gfoss] compilare QGIS-master su linux


Strk,

sai gia' come la penso suiprodotti gis che spostano i vertici di un 
archivioufficiale.


Se io ho un archivio di taglio regionale, e devo sezionarne na porzione 
per una consegna.

A parte i punti dove taglio, dove e' ovvio che deve aggiungere vertici.
Non mi aspetto che i vertici rimanenti vengano e debbano essere spostati.
Nemmeno di un micron.

Un software che fa' questo per me e' bugged.

Ma comunque saranno fatti di chi lo usa.

Io taglio con spatialite e sono sempre piu' convinto delle mie scelte.

A.

Il 01/10/2015 17:32, Sandro Santilli ha scritto:

On Thu, Oct 01, 2015 at 05:09:31PM +0200, Andrea Peri wrote:


Per risolvere problemi sulle geometrie la soluzione proposta e'
ridurne la precisione ?

La proposta e' di dare la possibilita' di condurre operazioni
su una griglia di precisione specificata. Si puo' scegliere
di rimanere sulla griglia dei numeri a virgola mobile, che e'
indubbiamente piu' perigliosa di una bella griglia a celle di egual
misura...

--strk;


___
Gfoss@lists.gfoss.it
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.
786 iscritti al 30.9.2015

Re: [Gfoss] compilare QGIS-master su linux


Ripropongo qui il mio intervento:


sai gia' come la penso suiprodotti gis che spostano i vertici di un
archivioufficiale.

Se io ho un archivio di taglio regionale, e devo sezionarne na porzione per
una consegna.
A parte i punti dove taglio, dove e' ovvio che deve aggiungere vertici.
Non mi aspetto che i vertici rimanenti vengano e debbano essere spostati.
Nemmeno di un micron.

Un software che fa' questo per me e' bugged.

Ma comunque saranno fatti di chi lo usa.

Io taglio con spatialite e sono sempre piu' convinto delle mie scelte.


Mi sfugge cosa ci fosse di trolleggiante nel mio intervento.
:-\
Io penso che sia utile discutere di queste fatti.

Va a tutto vantaggio degli utenti che vogliono usare detemrinati 
softwares, avere piu' opinioni e valutare.


A parte questo, ottima battuta.
Aperoll.
hahaha
:):)


A.

Il 01/10/2015 19:11, Luigi Pirelli ha scritto:

ma Andrea Peri che fa il troll lo potremmo chiamare 'Aperoll'?
Luigi Pirelli

**
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Elance: https://www.elance.com/s/edit/luigipirelli/
* GitHub: https://github.com/luipir
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* Mastering QGIS:
https://www.packtpub.com/application-development/mastering-qgis
**


2015-10-01 18:32 GMT+02:00 aperi2007 <aperi2...@gmail.com>:

Strk,

sai gia' come la penso suiprodotti gis che spostano i vertici di un
archivioufficiale.

Se io ho un archivio di taglio regionale, e devo sezionarne na porzione per
una consegna.
A parte i punti dove taglio, dove e' ovvio che deve aggiungere vertici.
Non mi aspetto che i vertici rimanenti vengano e debbano essere spostati.
Nemmeno di un micron.

Un software che fa' questo per me e' bugged.

Ma comunque saranno fatti di chi lo usa.

Io taglio con spatialite e sono sempre piu' convinto delle mie scelte.

A.


Il 01/10/2015 17:32, Sandro Santilli ha scritto:

On Thu, Oct 01, 2015 at 05:09:31PM +0200, Andrea Peri wrote:


Per risolvere problemi sulle geometrie la soluzione proposta e'
ridurne la precisione ?

La proposta e' di dare la possibilita' di condurre operazioni
su una griglia di precisione specificata. Si puo' scegliere
di rimanere sulla griglia dei numeri a virgola mobile, che e'
indubbiamente piu' perigliosa di una bella griglia a celle di egual
misura...

--strk;


___
Gfoss@lists.gfoss.it
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.
786 iscritti al 30.9.2015


___
Gfoss@lists.gfoss.it
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.
786 iscritti al 30.9.2015

Re: [Gfoss] compilare QGIS-master su linux

Non vorrei essere troppo trolleggiante.

Pero' forse devo spiegare meglio un punto:

Mettere i dati su una griglia non vuol dire assicurare la ripetibilita'.

Anche ora con la precisione FloatingPoint (FP64) il risultato e' ripetibile.
Basta usare i medesimi algoritmi.

Qui si parla di usare un algoritmo differente che effettui una qualche
operazione tesa a ridurre la precisione dei dati per fare la computazione.

Se tutti i software che conosciamo nel mondo GFOSS usano i medeismi
algoritmi :

gdal, mapserver, postgis, spatialite, etc...

possiamo ragionevolmenteritenere che i risultati saranno identici.
Forse qualche differenza potro' averla se confronto i dati da Linux con
quelli da Windows, ma ipotizzando di restare su windows ,

posso ritenere che i risultati son i medesimi.

Se peor' QGISsi smarca e usa algoritmi differenti, ecco che dara'
risultati differenti.

Saranno sempre ripetibili, ma differenti.

Per me questo e' un elemento molto negativo.

Pensa al caso di un perito che usa qgis per fare un progetto e ottine
dei srisultati.
Poi arriva un altro perito e per fare le verifiche usa altro software e
ottiene risultati differenti.

Chi ha ragione alla fine: il primo che ottiene 10 elementi o il secondo
che ne ottiene 12 ?

Il 01/10/2015 20:15, Geodrinx ha scritto:

Effettivamente, mi chiedo:
se, per garantire la ripetibilità del calcolo (per esempio dell'intersezione di
rette che proseguono dei segmenti), io vado a bloccare la precisione dei
risultati su una griglia, io otterrò un insieme di punti finiti e determinati,
e anche topologicamente corretti, ma allora per quale motivo ho utilizzato file
vettoriali ?

Facciamo un esempio chiarificatore: interseco due ellissi, oppure due cerchi,
oppure due funzioni matematiche. Voglio usare un GIS e setto questa griglia
nel calcolo. Quale step di griglia uso per non avere un risultato troppo
approssimato ?

Sicuramente c'è tutta una teoria matematica e informatica dietro questa scelta (nessuno fa cose di
questo tipo "a vanvera") però non sarebbe male essere informati su tutti quanti su cosa
dobbiamo cercare su Google per "farci una cultura" sull'argomento.

Scusate la digressione e grazie per qualunque info in proposito

Roberto

Inviato da iPhone

Il giorno 01/ott/2015, alle ore 18:32, aperi2007 <aperi2...@gmail.com> ha
scritto:

Strk,

sai gia' come la penso suiprodotti gis che spostano i vertici di un
archivioufficiale.

Se io ho un archivio di taglio regionale, e devo sezionarne na porzione per una
consegna.
A parte i punti dove taglio, dove e' ovvio che deve aggiungere vertici.
Non mi aspetto che i vertici rimanenti vengano e debbano essere spostati.
Nemmeno di un micron.

Un software che fa' questo per me e' bugged.

Ma comunque saranno fatti di chi lo usa.

Io taglio con spatialite e sono sempre piu' convinto delle mie scelte.

Il 01/10/2015 17:32, Sandro Santilli ha scritto:

On Thu, Oct 01, 2015 at 05:09:31PM +0200, Andrea Peri wrote:

Per risolvere problemi sulle geometrie la soluzione proposta e'
ridurne la precisione ?

La proposta e' di dare la possibilita' di condurre operazioni
su una griglia di precisione specificata. Si puo' scegliere
di rimanere sulla griglia dei numeri a virgola mobile, che e'
indubbiamente piu' perigliosa di una bella griglia a celle di egual
misura...

--strk;

Re: [Gfoss] compilare QGIS-master su linux


Ri-intervengo giusto per una correzione di dettaglio.

Erroneamente ho parlato di principio commutativo.
In realta' nell'aritmetica finita viene negato il principio distributivo 
e non quello commutativo.
Forse anche quello commutativo, ci dovrei riflettere un po', ma in ogni 
caso quello che impiegavo nell'asserzione


(A*B)/C <> A*(B/C)

e' il principio distributivo.

A.


Il 01/10/2015 23:58, aperi2007 ha scritto:
A scuola ci insegnano che in matematica vale il principio della 
commutazione su certe operazioni.


Per cui:

A + B = B *a

Questo principio non vale in senso generale in un mondo ad aritmetica 
finita.

Proprio a causa della propagazione dell'errore.

Se te fai:

(A * B) / C
in aritmentica finita non ' uguale a fare
A * (B / C)


___
Gfoss@lists.gfoss.it
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.
786 iscritti al 30.9.2015

Re: [Gfoss] compilare QGIS-master su linux


Quella che citi e' la cosidetta "teoria della propagazione dell'errore".
L'errore in ogni sistema ad aritmetica finita e' quantificabile , e in 
base a come disponi le operazioni puoi ridurlo.


A scuola ci insegnano che in matematica vale il principio della 
commutazione su certe operazioni.


Per cui:

A + B = B *a

Questo principio non vale in senso generale in un mondo ad aritmetica 
finita.

Proprio a causa della propagazione dell'errore.

Se te fai:

(A * B) / C
in aritmentica finita non ' uguale a fare
A * (B / C)

proprio a causa della propagazione dell'errore.

E si riesce a dimostrare di quanto si scostano i due valori.

Per cui quando devi impostare un algoritmo per svolgere un calcolo di 
precisione, devi stare attento a come imposti le formule nel linguaggio 
di programmazione proprio per minimizzare l'errore.


Nella teoria della propagazione dell'errore uno dei capisaldi e' che 
meglio operare su numeri grandi piuttosto che su numeri piccoli.


Per questo suggeriscono di togliere la virgola.

Si moltiplica per 10.000 , abbassando la virgola di 4 posti.
Si effettuano i conti e poi si divide per una cifra come ad esempio 
10.000 (sara' composta di un n.ro di cifre differenti in base al tipo di 
operazione svolte) per riportare la virgola al suo posto.

In quesotmodo si minimizza la propagazione dell'errore.

Senza dimenticare di impostare la formula commutandola in modo da 
minimizzare l'errore.


Ed e' tutta roba che non fa' perdere assolutamente un bit di precisione.

A.

Il 01/10/2015 21:37, Sandro Santilli ha scritto:

All'istituto che ho frequentato avevo una materia che si chiamava
"misure". Mi hanno insegnato a calcolare l'errore sulle misure e
come le varie operazioni li amplificano.
Gli elementi magari sono 10 ± 2, se la risposta e' consona.

A quanti metri si trova Firenze dal livello del mare ?
Quanto lontana dalla costa e' quella nave ?
Che area ha quella piazza ?

Si parla di modelli, devono essere utili, gestibili.


___
Gfoss@lists.gfoss.it
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.
786 iscritti al 30.9.2015

Re: [Gfoss] compilare QGIS-master su linux


Hai capito perfettamente cosa intendevo quando parlavo di ripetibilita'.

E' il problema che ci siamo trovati a gestire con un famoso geodb di un 
famoso software commerciale.
Il dato veniva spianato in una griglia, che nelle prime versioni era 
quantizzata su valori interi, nelle versioni successive era quantizzata 
su una griglia floating point, ma il concetto restava lo stesso.


Ovvero cambiando la griglia cambiava il risultato.
Se lo stesso dataset passava da due pc con due griglie differenti, e in 
ognuna di esse semplicemente inserito una nuova linea, l'intero dataset 
di riallineava sulla griglia di quel db e alla fine di aveva dataset che 
sulla carta dovevano essere ufguali salvo leggeri cambiamenti 
localizzati, ma che in realt'a presentavano differente micrometriche 
ovunque.


Questi archivi quando si andava a rimetterli insieme generavano casini 
impensabili.
Altro che soluzione per risolvere problemi, era la strada per incasinare 
sempre di piu'.


E' sempre la teoria del calcio al barattolo.
PEr semplificare un problema locale (la precisione finita su un problema 
di geometria) si sposta il problema a un altro livello , permettendo 
l'esistenza di dati che possono cambiare griglia a seconda del pc da cui 
passano.


Anche ora esisteuna griglia, ma e' quella fisica dettata dalla 
precisione finita del pc ovvero a FloatingPoint a 64 bit.

Ed e' uguale su tutti i comuter.
Il fatto che sia uguale su tutti i computer vuol dire che il dato che 
passa su tutti i computer resta empre uguale.


Ovviamente poi dipende da cio' che fa' l'utente , da che algoritmi 
utilizza, che software.

Ma quello e' un altro discorso.

Qui si sta parando di qualcoa che anche in caso di medesimo algoritmo, 
basta che adottiuna griglia differente che propone risultati differenti.


Br.

A.


Il 01/10/2015 22:39, a.furi...@lqt.it ha scritto:

On Thu, 1 Oct 2015 21:37:16 +0200, Sandro Santilli wrote:

Non mi sembra assurdo pensare di avere una griglia di riferimento
valida per tutti, per un determinato dataset.
Faccio un esempio: per la cartografia in scala 1:25, usare una 
griglia

di precisione millimetrica.



qua pero' si apre un oceano buio e procelloso.

personalmente sono abbastanza d'accordo sulla potenziale
utilita' di introdurre un fattore di approssimazione
"quasi infinitesimo", tipo il centomillesimo di centimetro
che citavi nell'altra tua mail.
puo' realisticamente servire per occultare le bizzarrie
piu' stravaganti del processore HW floating point, dei
flags piu' esoterici del compilatore e delle librerie
di runtime (magari subdolamente inlined e/o basate sul
set di istruzioni SSE per efficienza).

invece ipotizzare p.es. un millimetro per una determinata
scala 1:25 ci porta dritti sparati dentro ai peggiori
scenari che Andrea ha cercato di ipotizzare per mettere
in guardia contro gli ovvi trappoloni che aspettano gli
incauti lungo il cammino.

a te pare ragionevole 1mm, a me personalmente pare meglio
0.5mm, Andrea preferisce 0.001mm e magari qualche
utente sprovveduto potrebbe pensare che 5m sarebbe ancora
meglio.
troppo facile prevedere una ricca fioritura di scelte
assolutamente disparate e dettate piu' che altro dal
caso (e magari per nulla documentate nei metadati che
pure dovrebbero accompgnare qualsiasi dataset, e che
invece troppo spesso sono degli illustri sconosciuti).

mettiti un po' nei panni di chi poi si trovera' in fondo
alla filiera a cercare disperatamente di integrare in modo
robustamente consistente tanti dataset di origine diversa
(p.es. comuneA/comuneB/comuneC/provA/provB/regione/stato,
agenzia x, sopraintendenza y, azienda z e cosi' via).
ciascuno dei quali avra' verosimilmente utilizzato una
propria griglia di snap con un passo diverso da tutti
gli altri.

pare uno scenario che non preannuncia nulla di buono :-D

ciao Sandro






___
Gfoss@lists.gfoss.it
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.
786 iscritti al 30.9.2015

Re: [Gfoss] compilare QGIS-master su linux


Scusa se approfitto vigliaccamente.
:)

Non sono mai riuscito a comprendere bene cosa si potesse realmente fare 
con la topologia di grass.


Esiste un documento , un howto, un rfc che spiega un po' piu' addentro 
la parte topologica ?


La mia conoscenza della topologia di grass si ferma al fatto che quando 
carico uno shapefile , lui me lo scompone in polygon 0,1 e 2. Che va 
benissimo, per un certo tipo di uso, ma non per molti altri impieghi.
Non sono ancora riuscito a capire se invece riesco a gestire 
direttamente n editing a livello di topologia.


Per cui la mia impressione ad oggi e' che su grass si passa sempre da 
una simple-feature che si edita in qualche modo e poi si ricarica nella 
topologia di grass.


E quindi non sono mai riuscito a capire se si puo' e con qali comandi 
operare direttamente sulla topologia, inserendo , rimuovendo o spostando 
un arco o un nodo nella copertura topologica generata dal caricamento di 
uno shapefile di poligoni.


A.

Il 02/10/2015 00:52, Luca Delucchi ha scritto:

2015-10-02 0:38 GMT+02:00 G. Allegri :

In pratica sogno un sistema robusto quanto un GRASS (o il vecchio ArcInfo)
ma con una UX più semplice. La quadratura del cerchio :)

beh dai molti passi in avanti sono stati fatti:
- location wizard per aiutare gli utenti a creare la location
- diversi tool grafici quali: grafical modeler, interfaccia per stampa
sfruttando ps.map, tool per visualizzazioni avanzate
- possibilità di importare dati con sistemi di coordinate diverse da
quelle della location in uso (attualmente nella versione trunk)


Un bell'argomento di ricerca...


ovviamente sarebbe molto interessante avere anche altre
idee/soluzioni, ma poi ci vorrebbe qualcuno che la implementi :-)


giovanni



___
Gfoss@lists.gfoss.it
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.
786 iscritti al 30.9.2015

Re: [Gfoss] compilare QGIS-master su linux

Sarebbe l'uovodi colombo.

Se uno si immaginasse la potenza elaborativa della topologia ISO, poi 
non la abbandonerebbe piu'.

Il problema e' che propone un approccio completamente differente.
Un approccio che richiede anche un ripensamento delle metodiche di editing.
Soluzioni molto meno intuitive di un approccio simple-feature.

E' come paragonare un elicottero a un aereo.

L'aereo e' piu' semplice come movimento e quindi piu' veloce, 
l'efficienza si risolve nella velocita'.

L'elicottero e' molto piu' sofisticato e versatile perche' puo' fare dei 
movimenti che l'aereo non puo' fare.
Molto piu' agile, ma meno veloce, perche' ha un movimento piu' complesso 
ed e' molto piu' difficile da guidare perche' l'operatore deve 
contemporaneamente muovere due rotori indipendenti.

A.

Il 01/10/2015 23:37, G. Allegri ha scritto:

Domanda piccola piccola: ma perché non si persegue l'approccio con la 
coppia modello geometrico/modello topologico? Capisco che sia più 
complesso e oneroso da gestire e mantenere rispetto ad una 
pseudotopologia, ma evita d'infognarsi nei meandri delle precisioni.
So che, come Postgis, anche Spatialite lo sta implementando (grazie a 
Regione Toscana). Continuo a sperare che prima o poi QGIS implementerà 
i meccanismi in grado di usufruire di questa doppia natura...

giovanni

Il 01/ott/2015 22:54, "Sandro Santilli" > ha scritto:

On Thu, Oct 01, 2015 at 10:39:50PM +0200, a.furi...@lqt.it
 wrote:

> mettiti un po' nei panni di chi poi si trovera' in fondo
> alla filiera a cercare disperatamente di integrare in modo
> robustamente consistente tanti dataset di origine diversa
> (p.es .
comuneA/comuneB/comuneC/provA/provB/regione/stato,
> agenzia x, sopraintendenza y, azienda z e cosi' via).
> ciascuno dei quali avra' verosimilmente utilizzato una
> propria griglia di snap con un passo diverso da tutti
> gli altri.

Potrei prendere un'abbaglio, ma ho l'impressione che, matematicamente
parlando, applicando la griglia meno fitta tra tutte quelle utilizzate
comporterebbe un matching esatto dei vari dataset.

Semmai il problema sara' il _trovare_ la griglia applicata ad ognuno
dei dataset, se non si conta sui metadata. E' per quello che parlavo
di "griglie standard di riferimento". Potrebbe essere un riferimento
normativo.

--strk;
___
Gfoss@lists.gfoss.it 
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.
786 iscritti al 30.9.2015

___
Gfoss@lists.gfoss.it
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.
786 iscritti al 30.9.2015

Re: [Gfoss] Grigliati IGM et similia: se ne occupa il Parlamento (Commissione Difesa)

2015-09-15 Per discussione aperi2007



Scusa, ma purtroppo per carenze mie non ho capito.

Te dici di aver voluto testare la fedelta' rispetot ai moelli IGM.

E poi pero' parli di accuratezza.

Sono due cose differenti.

Fedelta' al modello OGM vuol dire che restituiscono il medeismo 
risultato il piu' possibile fedele, ovvero con uno scarto infiitesimo.

Piu' e'' picoclo e meglio e'.

Poi pero' per le conclusioni non parli di quanto sono risultait fedeli, 
ma piuttosto della loro accuratezza.

Accuratezza e' rispetto a una misurazione sul campo.
E quindi e' quanto essi sono accurati rispetot alla realta'.
Che e' una altra storia.

Puoi spiegarmi meglio ?

Grazie.

Andrea.

Il 15/09/2015 17:26, Mattia De Agostino ha scritto:

Qualche mese fa, insieme ad altri membri (anche illustri! ) della lista
abbiamo voluto testare proprio la "fedeltà" di questi modelli interpolativi
(compresi quelli di PROJ contenuti in QGIS) rispetto alle trasformazioni
ufficiali IGM (aka: i grigliati). Questo lavoro verrà presentato ad ASITA,
nella sessione poster di mercoledì.
I risultati? In sintesi, i modelli interpolativi nazionali, quali ad esempio
Traspunto (e quindi i grigliati Globo) hanno effettivamente un'accuratezza
metrica su quasi tutto il territorio nazionale. Un esempio, proprio per la
trasformazione del modello Traspunto, è qui:


___
Gfoss@lists.gfoss.it
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.
750 iscritti al 18.3.2015

Re: [Gfoss] perchè non mandiamo una petizione per ottenere le mappe catastali gratuitamente

2015-09-11 Per discussione aperi2007


Concordo in pieno con l'avvertimento.
Anche io sono convintissimo che i dati del catasto cartograficamente 
parlando non sono utili se non consierati assieme ad altri dati e 
gestiti con consapevolezza.


Condivido una immagine che e' vale piu' di molti discorsi.
(ps : non so' quanti giorni potro' tenere questa immagine linkata per 
cui consideratelo a scadenza)


https://www.dropbox.com/s/emae9d39vu2kkn7/immagine.gif?dl=0

Ho cerchiato in rosso la parte che evidenzia una delle caratteristiche 
salienti del dato catastale.
La sua insovrapponibilita' (anche cambiando sistema di riferimento) al 
dato cartografico.
Poi, come e' ovvio si puo' anche sovrapporre se proprio si vuole, ma 
occorre essere consci del fatto che non dovrebbero essere sovrapposti e 
gestire opportunamente le incongruenze presunte che ne derivano.


Proprio in questi giorni abbiamo dato risposta ad una segnalazione che 
intendeva informarci di un problema sui dati catastali.


A parte il fatto che non avevamo titolo per operare correzioni in tal 
senso, era giusto dare una traccia per la spiegazione e quindi abbiamo 
inviatouna risposta sintetica.

Risposta che ritengo sia utile condividere.

La risposta non è farina del mio sacco (magari lo fosse), ma bensi' di 
un mio collega molto esperto diqueste problematiche di confronto tra 
dati eterogenei. Uno che purtroppo (egoisticamente parlando) sta per 
andare in pensione e presto non sara' nel nostro team ad aiutarci in 
questo complicato mondo dei dati geografici.


--
Buongiorno,
La traslazione che ci segnala non è considerata, dal punto di vista 
tecnico, una "anomalia", per almeno i seguenti motivi principali:


1. le mappe catastali non hanno una struttura geometrica di tipo 
topologico. Ciascun foglio, suddiviso in particelle, rappresenta una 
porzione di territorio al cui interno gli "oggetti" rappresentati sono 
rilevati compiutamente. In altri termini, una strada o un torrente posti 
sul confine fra due fogli adiacenti, vengono cartografati completamente 
in ciascuno dei due fogli risultando, per questo motivo, duplicati.
2. le mappe catastali sono realizzate con metodologia di rilievo, 
sistema di riferimento e sistema di coordinate, diversi da quelli 
utilizzati per la realizzazione delle cartografie topografiche (carte 
tecniche regionali) e delle orofotocarte, cioè delle immagine aeree 
ortoproiettate su DTM e georeferenziate tramite parametri congruenti con 
le carte topografiche.


Nel ringraziare per la sua gentile segnalazione, trasmettiamo cordiali 
saluti

-

Saluti a tutti e buon we.

A.


Il 10/09/2015 19:09, Arch. Fabio Saccon ha scritto:


2 Strumenti di questo genere sono utili ma non indispensabili se 
considerati fine a se stessi. Cartograficamente sono pessimi e senza 
informazioni non servono.


3 Per implementare cartografia di tipo urbanistico, tributario etc. 
attraverso il comune riesci ad averle.




___
Gfoss@lists.gfoss.it
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.
750 iscritti al 18.3.2015

Re: [Gfoss] perchè non mandiamo una petizione per ottenere le mappe catastali gratuitamente

2015-09-11 Per discussione aperi2007


A quello che saprei io
La posta certificata certifica solo la ricezione del messaggio.
Non il suo contenuto.
E comunque si parla di allegati di dimensioni considerevolmente 
superiore al massimo ammissibile da un invio in posta certificata.


Anche perche' quando si paga un accounti di posta certificata ce 
qualcuno che deve archiviare e conservare il messaggio. Per cui si 
supererebbe presto i limiti di capacita' e quindi altri costi occulti 
per chi dovrebbe invece risparmiare.


Per me l'invio di dati vettoriali tramite posta certificata non 
funzionerebbe proprio.


A.

Il 11/09/2015 15:49, Salvo caligiore ha scritto:


Il giorno 11/09/15 15:03, "stefano campus"  ha scritto:


quello che forse maldestramente volevo dire è che il dato catastale,
avente
rilevanza giuridica e probatoria di un qual certo peso DEVE, secondo me,
essere rilasciata solo dal titolare del dato o in ogni caso distribuito da
un ente che abbia titolo a farlo.


Se è necessario solo la rilevanza giuridica e probatoria perché non far
pagare solo quello con file firmato digitalmente dall¹agenzia del
territorio mentre per tutti gli usi in cui la rilevanza giuridica e
probatoria  NON è necessaria, lasciare il libero download e possibilità di
copia





?
per i costi che un'infrastruttura geografica ha, secondo me, è
perfettamente
non solo legittimo (per quello basta una norma) ma anche "moralmente"
giusto chiedere un corrispettivo.

s.


Scusa mi fai un esempio dei costi di cui stai parlando?

Perché
  1) l¹infrastruttura geografica attualmente non c¹è , il sistema di
download per i comuni delle mappe catastali non è un gis, ma solo un
download di files specifici.

2) i costi comprendono server e personale non capisco perché sia
moralmente giusto chiedere sti soldi per i dati catastali , e non per la
gazzetta ufficiale , oppure per le mappe tematiche dei sit per sentenze di
tribunale perché proprio le mappe catastali è giusto che siano pagate il
resto no?

3) una volta che si pagano sti dati  posso fare tutte le copie che voglio?
Ci posso fare quello che voglio anche stamparli e appendermeli nel cesso?


___
Gfoss@lists.gfoss.it
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.
750 iscritti al 18.3.2015


___
Gfoss@lists.gfoss.it
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.
750 iscritti al 18.3.2015

Re: [Gfoss] perchè non mandiamo una petizione per ottenere le mappe catastali gratuitamente

2015-09-11 Per discussione aperi2007


Possibile che basti tale riferimento ?
Anche l'utm ha valori di x inferiori al milione.


Il 11/09/2015 14:50, Geo DrinX ha scritto:
Per evitare di perdere tempo reciproco, le coordinate CassiniSoldner 
si riconoscono dai valori di X, inferiori a 1 milione.


___
Gfoss@lists.gfoss.it
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.
750 iscritti al 18.3.2015

Re: [Gfoss] [QGIS] - viste postgres senza gid di default

2015-08-31 Per discussione aperi2007


Ciao Luca.

Ti comprendo benissimo e' proprio il modo di fare di chi gestisce QGIS 
che a me fa parecchio inqueitare.

Il prendere decisioni e fare cambamenti senza porsi troppi problemi.

Non parlo di aggiungere roba nuova, ma piuttosto di modificare 
comportamenti radicati da tempo.


E' un bruttissimo vizio di chi scrive programmi. Pensare che chi li usa 
debba sempre adattarsi a cio' che lui pensa sia giusto.


Ed e' per questo che io a volte sono molto critico nei confronti di qgis 
e di chi lo gestisce.
A volte fanno scelte di cui non si capisce bene la logica, se non quella 
di soddisfare specifiche e puntuali esigenze di tizio o caio, ovviamente 
a spese di tutti gli altri.


Tra l'altro faccio notare che a queloche si sapeva, la 2.8.x era in LTS 
e quindi avrebbe accettato solo risoluzioni di BUGS e non evoluzioni.

A quanto pare anche questo non e' vero.
Perche' se nella 2.8.2 questa cosa non ce' e nella 2.8.3 invece si', 
allora vuol dire che quando serve a qualche "unto" le evoluzioni nella 
versione LTS si mettono eccome.

:)

Detto questo pero', ti invito a pensarci bene anche ai pro' e contro.

Tieni infatti presente che se un donani vi salta fuori un bug sulla 2.8.2
la sua risoluzione sar'a interamente a carico vostro e inoltre sarebbe 
specificasulla 2.8.2 , senza alcun beneficio di porting su nuove 
versioni. Dove magari nemmeno il bug e' presente.
Inoltre perdereste tutte le evoluzioni nuove che ci sono nelle nuove 
versioni.


E infine, se la vostra permanenza sulla 2.8.2 durasse troppo a lungo.
Quando e se decideste di passare alla ultime versione potreste scoprire 
che siete troppo vecchi e il nuov qgis non riesce a importarvi 
correttamente i vostri progetti.


Insomma, ti capisco benissimo e sono molto critico, ma valutate anche i 
contro nel medio periodo perche' se vi bloccate sulla 2.8.2 per questa 
cosa, rischiate di ritrovarvi da soli a gestire problematiche di varia 
natura.


E sara' una fregatura e una penalizzazione anche per QGIS stesso.
Perche' ovviamente se sei costretto a usare la 2.8.2 finisce che non hai 
motivo di partecipare a nessun finanziamento di nuove evoluzioni.
Visto che andrebbero a ingrassare una versione che te non puoi o hai 
scelto giocoforza di non usare.


A.

Il 31/08/2015 19:37, Luca Lanteri ha scritto:


> Per dirla finemente, come per la corazzata potemkin, secondo me è  
una cagata galattica!

>
> Rende impossibile caricare più viste insieme e per gli utenti meno 
smaliziati sembra che le viste non funziomino. tutte le volte si deve 
definire per ogni vista il gid.

> Rimmarremo sulla 2.8.2.
>
> Provo a scrivere il lista qgis perché ti assicuro da utente che è 
una scelta decisamente sbagliata.

>
> Grazie paolo
>
> Luca



___
Gfoss@lists.gfoss.it
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.
750 iscritti al 18.3.2015


___
Gfoss@lists.gfoss.it
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.
750 iscritti al 18.3.2015

Re: [Gfoss] QGIS - suggerimento

2015-08-20 Per discussione aperi2007

Intendi dire che QGIS non salva un inserimento o modifica sui dati di un 
layer se tale layer e' agganciato a una vista ?


Le viste di postgres non credo che siano read-only.
Certo dipende da come la si costruisce e che cosa ci si mette dentro, ma 
non dovrebbe dipendere dal fatto di essere una vista.


A.


Il 20/08/2015 23:33, Totò Fiandaca ha scritto:

Le rispondo molto volentieri.
Quasi sempre sono io in prima persona che, attraverso rilievi in 
campo, mi creo il dato GIS da zero, con questo voglio dire che uso 
poco i dati gia preparati o presenti nel web.
Questo mi porta a lavorare molte ore sia nella creazione del geoDB sia 
nella digitalizzazione degli strati (qgis) e capita alcune volte 
(molte volte in realtà) di dover modificare dei layer, editare nuovi 
poligoni ecc
quindi, quando lavoro solo da qgis mi sarebbe molto utile distinguere 
se un layer è una vera tabella oppure una virtuale, anche perchè 
finchè non si salva il lavoro, qgis, non ti avverte che sto cercando 
di modificare una view.


tutto qua, ma forse è un problema tutto mio.
comunque parecchi usano, me compreso, la 'v_' davanti al nome della vista.

buona serata


Il giorno 20 agosto 2015 23:12, Andrea Peri aperi2...@gmail.com 
mailto:aperi2...@gmail.com ha scritto:


Scusa ma la cosa mi aveva incuriosito.

Miincuriosiva capire perche' ti serve sapere distinguere una vista da
una tabella in un GIS.
Per quello che ne sapevo io, a livello di GIS non dovrebbe esserci
alcuna differenza se il layer e' alimentato da una tabella o da una
vista.

Una vista e' differente come struttura in un dbms, maquesto e'
completamente trasparente a un GIS.
O dovrebbe esserlo che io sappia.

Mi spiego in altro modo.
Se mi dici che ti farebbe comodo avere una piccola i sulla legena
per capire se il layer ha la geometria indicizzata spazialmente.
Ne avrei capito l'utilita', anche se comunque credo che mettere una
i sopra un simbolo lo altera e quindi finisce per scontentare molti.
Ma il punto e' che ha una sua utilita' perche' permette di sapere che
quel layer e' lento perche' non è indicizzato spazialmente.

Mi incuriosiva capire quale fosse il caso di uso per cui serve sapere
che e' una vista dal punto di vista (scusa ilgioco di parole) del GIS.
Tutto qui.

:)


Il 20 agosto 2015 22:56, Totò Fiandaca pigrecoinfin...@gmail.com
mailto:pigrecoinfin...@gmail.com ha scritto:
 Beh, a me servirebbe, soprattutto se sono molte,
 Perché non è possibile distinguerle e ogni volta bisogna bisogna
aprire o
 pgadmin o dbmanager.

 Ma è solo una mia opinione.

 Il 20/ago/2015 22:17 Andrea Peri aperi2...@gmail.com
mailto:aperi2...@gmail.com ha scritto:

 Ma a che serve far sapere che uno strato in legenda proviene da
una vista
 ?
 Un utente standard non deve nemmeno sapere che esiste una vista.

 Apre il progetto, panneggia, zooome interroga, stampa e fine.
 Se vede un simbolino V messo da una parte nella legenda e poi
non lo
 ritrova nella mappa pensa che non siano la stessa cosa.

 Intorbidire i simboli della legenda nella TOC aggiungendoci una V
 sopra per rappresentare le viste potrebbe convincere altri utenti a
 non usare le viste.
 E quindi rinunciare a un altro vantaggio nei confronti di
arcgis (che
 per l'appunto non supporta le viste nel suo geodb)


 A.


 Il 20 agosto 2015 21:32, Totò Fiandaca
pigrecoinfin...@gmail.com mailto:pigrecoinfin...@gmail.com ha
 scritto:
  anche io utilizzo la tecnica della 'v' ma non mi sembra
elegante ed
  inoltre
  sarebbe una personalizzazione che non tutti capirebbero.
  Si, sapevo che da DBmaneger si riconosco; ma perchè non farlo
nella TOC?
  basterebbe far comparire una piccola 'v' nel simbolo: poligono,
  polilinee o
  punti.
  ciao
 
  Il giorno 20 agosto 2015 20:51, Paolo Cavallini
cavall...@faunalia.it mailto:cavall...@faunalia.it
  ha
  scritto:
 
  Da DBmanager si riconoscono facilmente.
  Saluti.
 
  Il 20 agosto 2015 20:20:29 CEST, Umberto Zulian
uzul...@hotmail.com mailto:uzul...@hotmail.com
  ha
  scritto:
 
  io avevo iniziato rinominando la view appena caricata in
qgis, poi ho
  fatto il gruppo delle view, adesso la nomino direttamente
in postgis
  quando
  la creo (es. v_zonerischio)
 
  ciao
 
 
  
  Date: Thu, 20 Aug 2015 19:04:26 +0200
  From: pigrecoinfin...@gmail.com
mailto:pigrecoinfin...@gmail.com
  To: gfoss@lists.gfoss.it mailto:gfoss@lists.gfoss.it
  Subject: [Gfoss] QGIS - suggerimento
 
  Salve a tutti,
  lavorando con QGIS/PostGIS utilizzo molto spesso le 'view' e mi
  chiedevo
  come fosse possibile capire (dal riquadro 'legenda' di
QGIS) quali
  layer

Re: [Gfoss] QGIS - suggerimento

2015-08-20 Per discussione aperi2007


Ok, questo mi torna.
Ma allora la segnalazione che servirebbe non è che e' una vista, ma 
bensi' che sia editabile.


Infatti potrebbe anche essere un layer che proviene da un dvd o da una 
cartella read-only di un server.
Ma questo tipo di segnalazione esiste gia' in qgis. Infatti se ricordo 
bene ,
qgis tiene disabilitato il pulsante di editing quando rileva che la 
risorsa e' read-only.


Spero di non ricordare male.
Con i layer sql sicuramente lo faceva e immagino che continui a farlo 
anche ora. Con gli altri non ho certezze.


Qundi , l'ideale con le viste sarebbe che nel caso essa fosse read-only 
, qgis dovrebbe tenere il pulsante disabilitato.


Per cui e' reso impossibile mettere in editing tale vista.

Il fatto pero' qui e' che a priori qgis non riesce a sapere se una vista 
di postgres e' scrivibile finche' non ci prova a scrivere e riceve il 
diniego da postgres stesso.


A.

.Il 21/08/2015 01:24, Sandro Santilli ha scritto:

Ad ogni modo indubbiamente sarebbe utile avvertire se un layer e'
o non e' editabile prima di fartici perdere tempo.


___
Gfoss@lists.gfoss.it
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.
750 iscritti al 18.3.2015

Re: [Gfoss] QGis Grass PlugIn 2.0

2015-08-03 Per discussione aperi2007


tra i punti.

Il 03/08/2015 17:18, Sandro Santilli ha scritto:


E' invece un problema per uno stakeholder pubblico, il quale ha
difficolta' a operare con queste modalita'.
Non che non si possa in assoluto, ma sicapisce bene che se si da' un
incarico a un developer di studiare un problema, non si puo' poi
dargli un nuovo incarico per l'implementazione del lavoro stesso.
Scusa ma io questo non lo capisco. Non si capisce bene, almeno io
non lo capisco bene. Perche' un ente pubblico non puo' dare un
incarico per la sola analisi e progettazione ? Non e' proprio la
pianificazione una delle fasi piu' importanti in qualunque progetto ?


Certo, ma il problema e' la sequenzializzazione in due incarichi 
distinti e differenti, alla medesima persona.

Il primo per progettare e il secondo per realizzare.
Potrebbe essere inteso come frazionamento.


Ma qui nasce poi il secondo problema:
Ovvero, la community stessa, la quale e' essa stessa una entita che
oserei definire liquida e variabile.

Il risultato di questa liquidita' e' che cambia spesso opinione,
dimentica cio'che e' stato fatto, si focalizza troppo su l'oggi e
sottovaluta la visione strategica di un prodotto.

Questa mi sembra una generalizzazione, e bisognerebbe portare
esempi specifici e concreti per capire meglio di cosa parli.


Ma che esempi.
Uno non lo fa' mica di mestiere di partecipare tutti i giorni alla 
community.

Te stesso leggi solo ogni tanto.
Quindi il tuo pensiero e' presente a sprazzi.
Idem per chiunque altro. Per cui le opinioni variano in relazione a chi 
legge e risponde.


Non mi pare che sulla community di qgis organizzino votazioni dando 
tempi settimanali per esprimere pareri. Chi risponde risponde, poi le 
decisioni sono prese sulla base di cio' che e' stato detto.




La modalita' aperta dello sviluppo rende davvero difficile
dimenticare qualcosa di quel che e' stato fatto.


NOn sto dicendoche le cose vanno perse, ma una volta che un rilascio di 
qgis ha rotto qualcosa , te lo tieni in tal modo.
Non e' che chi lo ha rotto , si prende la briga di rimettere le cose a 
posto, e se anche lo facesse, prima del successivo rilscio non sarebbe 
nuovamente disponibile.


Te continui a vederla con l'ottica di uno sviluppatore che sicompila da 
se' il prodotto. E quindi no ti preoccupa questo genere di cose perche' 
ci metti 30 minuti a ricompilartelo su linux
Ma se pensi di essere un tecnico di un ufficio che deve fare un lavoro , 
che il tuo qgis non funziona piu' come ti aspettavi , e non puoi 
riprendere la vecchia versione perche' e' mancante di alcune 
funzionalit'a che ti servono pure esse, mica puoi aspettare 3 mesi per 
riavere una vesione funzionante per benino.



Per quanto riguarda la visione strategica, entra in gioco la capacita'
del proponente di convincere i maintainer della validita' di un approccio.
Mi viene in mente il caso di Pierre Racine con i PostGIS Raster.
Non solo Pierre non era nel PSC, ma non era neanche uno sviluppatore.
Da utilizzatore ha lavorato su un piano strategico cosi' dettagliato
e convincente da far digerire perfino a Paul Ramsey l'idea di
supportare i raster nel db (lui ne era notoriamente contrario).
Va da se che se Pierre non si fosse anche occupato di trovare i fondi
per finanziarne lo sviluppo difficilmente la cosa sarebbe andata
avanti (nel senso che non basta convincere a parole, ma bisogna pure
offrire la nuova funzionalita' ...)


L'approccio bazar , alla lunga finisce per far nascere anche lui i
forks , perche' costringendo gli stakeholders a difendrsi dalla
inevitabilita'del rischio del cambio bottone - zip li spinge a
ricercare la sicurezza nella tranquilla oasi di un fork
istituzionale.

A me sembra un problema generale legato ai cambiamenti.
Non e' specifico del software libero, ma ben presente anche con quello
proprietario. Nel software libero semmai e' attenuato proprio perche'
avendo il diritto legale di distribuire il software non si pone mai il
problema di non trovare piu' disponibile una versione vecchia di un
programma (avendo l'accortezza di tenerne copia).

Se poi parliamo di funzionalita' scomparse e' un altro paio di
maniche, e rinnovo il mio invito a segnalare tali casi come bug.


Si certo, ma vale il discroso sopra detto.
Se rilevi questo problema su una versione rilasciata , nel caso peggiore 
hai 3 mesi per riavere le cose a posto.

Una era geologica , in certe situazioni.


Come avere una visione strategica comune.

Partecipando alle liste di discussione.


Due problemi:
il prim piu' terreno e' il seguente:

Te immagina di essere il boss diuna ditta che lavora nei GIS, e hai i 
tuoi dipendenti , da cui dipende il tuo business. Devi fre una consegna 
importantissima, entro le porissime 4 settimane.
Te vai a dire ai tuoi dipendneti, di destinare parte del loor tempo per 
partecipare alle discussioni nelle Mailing List perche' devono 
presidiare il software da cui dipende il tuo business ?


I dipendenti, o lavorano e producono o presidiano le ML.
Entrambe le cose in orario

Re: [Gfoss] QGis Grass PlugIn 2.0

2015-08-02 Per discussione aperi2007


NOn il tuo modello e' sbagliato.

Il 02/08/2015 12:04, Luca Mandolesi ha scritto:


1 - Prendo Qgis 2.8 interno alla mia ditta perchè mi garba quello è 
stabile ecc. e pago un programmatore per farmi il pezzo in più e uso 
solo la 2.8 da qui a 5 anni (nella mia ditta andiamo avanti con la 2.4 
ancora e nessuno ha problemi)




Mettimao che domani a te serve una funzionalit'a core che qgi non fa' e 
che a te serve perche' altrimenti non porti a termine un lavoro importante.


Te finanzi l'evoluzione sulla tua vecchissima 2.4.

Ma a te chi ti dice che il programmatore per far l'evoluzione che te gli 
hai commissionato non intervenga pesantemente sul codice apportando 
modifiche che rendono a lui molto semplice lo sviluppo, ma renda il qgis 
forked molto differente rispetto a quello originale ?


Un conto e' apportare una patch per risolvere un bachettino, un altro e' 
aggiungere una cosa che manca.

Metti che domani ti serve il 3D e lo devi finanziare da zero.
Mettereil 3D su qgis non è uno scehrzo.
Te prendi metti sulpiatto 40.000 euro e lo fai fare alla tua 2.4 da una 
ditta.


La modifica va in profondita', devono aggiungere librerie nuove, 
modificare comportamenti, fare modifiche all a semantica dei files di 
progetto di qgis, magari cambiano nche la struttura delle finestre di 
interfaccia.


Te demandi qtutte queste scelte alla tua ditta selezionata.
Lei ovviamente opera in autonomia, e' il tuo unico interlocutore, le 
decisioni le prende lei.


Questo portera' sicuramente a un codice molto differente rispetto a 
quello originale di qgis.


2 - Rilascio il pezzo evoluto e la qgis.org http://qgis.org lo può 
prendere e finanziare l'inserimento nella dev.


Si, in teoria potrebbe, ma non e' obbligata a farlo.
E se per farlo deve pagare e trovare qualcun che finanzia cio' capisci 
bene che finisce che si paga due volte il medesimo lavoro Se va bene.






Ma in realta' non andrebbe come pensi te.

In realta' quello che succedera' e' che nessuno si prendera' la briga di 
dare una occhiata al codice di qgis-forked perche' sara' molto 
probabilmente completamente differente, magari non si compilera piu' 
nemmeno con i medesimi compilatori, e forse richiederebbe anche nuove 
librerie non previste dal qgis originale.
A quel punto se la qgis.org volesse fargli una occhiata dovrebbe pagare 
qualcuno per dargli una occhiata e il responso sarebbe molto 
probabilmente del tipo:


il codice e' molto differente e non e' chiaro se vale la pena recuperarlo.
Se si vuole quella funzionalit'a conviene rifarla daccapo.

A questo punto la cmmunity te pensi che finanzierebbe il 3D ?

Ma manco ci pensa.
Perche' chi ne aveva interesse cioe' te, ha gia' finanziato lo sviluppo 
sul suo qgis 2.4 forked e quindi perche' dovrebbe pagarlo di nuovo ?


A questo punto che fine fa' qis ?
Diventerebbe una sorta di universo di tante versioni ognna con qualcosa 
in piu' e qualcosa in meno e nessuno che ha interesse e forza per 
rimettere tutto insieme.


chi ha avuto il vantaggio ?

Ti racconto un caso realmente avvenuto:
circa3 o 4 anni fa' , quando qgis era gia' passato alla versione 2.0, ci 
fu' una universita' straniera che contatto' la community di qgis, 
perche' avevano tempo addietro preso un qgis credo fosse la 1.8 e 
avevano di loro inizitiva su di esso effettuato tutta una serie di 
modifiche per evolverlo portandoci dentro nuove fnzionalita' di 
elaborazione , mi pare nel settore idraulico.
E ora volevano rilasciare tutto Gfoss e ci tenevano che venisse recepito 
nel nuovo qgis.

Tutta roba bellissima e molto interessante.

Ma la risposta della community di qgis fu' assolutamente negativa.
Era logico.
Gli davano sostanzilmente un qgis 1.8 da doversi ristudiare daccapo per 
prelevare cio' che era stat fatto e cambiato. E ri-implementarlo su un 
qgis 2.0


Grazie tante, ma tenetevelo, e' roba sviluppata su una vecchia versione 
di qgis e non è possibile portarla all'ultima versione.


Poi, ovviamente se ce' chi paga magari profumatamente, tutto si fa'.

Questo fu' il responso.
Logico.

E ora credo che chi si vuole usare quel bellissimo codice idraulico se 
lo deve usare su un vecchioqgis 1.8 scaricabile da quella universit'a 
straniera.

E pure in una lingua straniera, anche il manuale.
Non mi ricordo quale fosse, forse era ungherese ?

:)

A.


___
Gfoss@lists.gfoss.it
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.
750 iscritti al 18.3.2015

Re: [Gfoss] QGis Grass PlugIn 2.0

2015-08-02 Per discussione aperi2007


Il modello di sviluppo di qgis e' tarato per venire incontro alle
esigenze dei developers.
Ma non prende in considerazione i problemi eventuali degli stakeholders.
Su qgis insistono varie tipologie di stakeholders.

Ma tra di essi la PA e' uno stakeholder complicato.
Perche' , a differenza, di un privato (una ditta o un libero
professionista) opera su dei vincoli ben precisi. Delle norme a cui
deve rigorosamente attenersi.
Non entro nel discorso se siano giuste o sbagliate (comunque per me sono
sono giuste). Ci sono e tanto basta. Non si possono ignorare.


QGIS tenta di proporre un modello unificato per i vari stakeholder:

-chiedi cio' che ti serve, discutiamone in lista, mettiamoci daccordo 
su come va fatta, la funzionalita' che finanzi ci sara' nella prossima 
versione rilasciata-


La prima cosa che a me salta agli occhi e' il problema procedurale che 
questo approccio fa nascere.
Esso presuppone di poter discutere fin dal principio con chi sviluppa o 
quanto meno con un soggetto che abbia ben chiaro cio' che serve, ma 
anche che sia in grado di interloquire sul livello di dettaglio 
necessario per poter tarare tecnicamente l'intervento da compiersi.
Il soggetto che si interfaccia con la community o con il gruppo 
decisionale per perorare la causa della evoluzione che si vuole compiere 
non puo' che essere colui che alla fine fara' il lavoro. Perche' quasi 
mai (ma potrei dire mai) chi finanzia ha un livello tecnico sufficiente 
per discutere di certi dettagli tecnici implementativi.


E' vero che questo non è un problema per uno stakeholder privato, che 
usualmente separa in due momenti distinti la fase di valutazione del 
lavoro dalla fase di implementazione vera e propria.
Egli infatti puo' commissionare a un developer il lavoro di studio del 
problema, costui effettua una indagine, valuta le varie problematiche e 
poi formula una ipotesi. Poi a fronte della relazione ricevuta dal 
developer, lo stakeholder privato potra' scegliere di estende al 
medesimo developer l'incarico dandogli il nulla osta al lavoro, oppure 
stoppandolo se ritiene che la soluzione proposta non sia accettabile per 
il suo fabbisogno o troppo costosa, o altri motivi.


E' invece un problema per uno stakeholder pubblico, il quale ha 
difficolta' a operare con queste modalita'.
Non che non si possa in assoluto, ma sicapisce bene che se si da' un 
incarico a un developer di studiare un problema, non si puo' poi dargli 
un nuovo incarico per l'implementazione del lavoro stesso.
L'incarico deve essere unico e complessivo. Per cui, non è opportuno 
separare in due fasi distinte.
Senza contare che la separazione in due fasi potrebbe portare ad avere 
soggetti differenti, esponendo anche al rischio che il secondo soggetto 
(quello implementatore) rimetta in discussione quando preparato dal 
primo soggetto progettista (chiamiamolo progettista per semplicita').


Questo e' il primo grosso problema che incontra una PA nell'approcciare 
uno sviluppo su QGIS.
Questo problema pero' e' comune a tutti i softwares Gfoss, ed e' la 
ragione per cui spesso si assiste alla nascita di forks di prodotto. 
Perche' non potendo separare facilmente la progettazione dallo sviluppo, 
e dovendo assegnare tutto a priori, finisce che chi ha l'incarico tende 
a fare un fork del prodotto.


Per parecchie ditte infatti la formulazione dell'offerta non contempla 
una interazione preventiva con la community , che viene invece vista 
come facente parte gia' della fase lavorativa.

Ovvero, prima di prende il lavoro e poi si interloquisce con la community.

Quando l'approccio e' questo, la conseguenza e' un fork , oppure una 
crescita dei costi (a posteriori).
Non si puo' infatti escludere che l'interazione con la community possa 
portare a una revisione di cio' che si prevedeva di fare.


Infatti in sede di offerta lo sviluppatore che opera secondo il modello 
classico tende sempre a identificare una strada di esecuzione del lavoro 
basandosi sul capitolato del committente, che ovviamente non puo' 
scendere cosi' in dettaglio, e cerchera' sempre la strada piu' agile e 
rapida per lo svolgimento del lavoro (quello che citavo nella altra 
email , dicendo che cerca sempre la strada piu' facile e rapida)  e su 
di essa formula il prezzo su cui viene poi dato l'incarico. Poi , dopo 
aver avuto l'incarico e iniziato a lavorare , interagendo con la 
community, si sente dire che deve seguire altre strade, piu' complicate 
e non previste. Conseguenza: I costi cambiano, aumentano. Il problema si 
sposta subito sul piano commerciale sottoponendo la scelta al suo 
committente. Le soluzioni proposte a quel punto sono le solite ovvie:
accettazione di un fork. Cioe' una versione fatta nei modi 
originariamente previsti e che mai sara' accettata dalla community di QGIS.

Oppure, una revisione dei prezzi, che sicuramente non sara' piccola.

Questo tipo di problema oggi in qualche modo, si riesce a superare.
Si riesce a superare perche' stanno nascendo un numero di ditte che

Re: [Gfoss] QGIS 2.8 – Salvare permanentemente un'espressione associata ad un campo di output

2015-08-01 Per discussione aperi2007

In ogni caso il corollario che aggiungerei al suggerimento e' di
annotarsi il valore del campo univoco relativo a un paio di geometrie note.

Dopo aver effettuato la modifica, salvato il dbf e sostituito, riaprire
lo shapefile con
qgis e andare a vedere se i due oggetti geometrici di cui ci si era
annotato il valore propongono ancor ai medesimi valori.

Non basta infatti limitarsi ad aprire lo shapefile modificato con qgis
verificando che si apre e si vede l'immagine sulla canvas, o che lo zoom
e il pan funzionano ancora.

Il problema potrebbe essere sulla corrispondenza dei valori , lo
shapefile non viene corrotto da una tale operazione, ma potrebbe subire
lo sparpagliamento dei valori degli attributi.

Il 01/08/2015 09:15, Sieradz ha scritto:

/
Andrea Peri wrote

a far danni e' un attimo

Concordo: agire direttamente sul DBF e' come un'operazione a cuore aperto,
che puo' salvarti la vita ma ad altissimo rischio.

Non dubito comunque che Marco sia un prudente 'power user', e che quindi si
faccia una copia di backup del DBF medesimo, prima dell'editing in
Libreoffice.

--
View this message in context:
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/QGIS-2-8-Salvare-permanentemente-un-espressione-associata-ad-un-campo-di-output-tp7593339p7593343.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian
mailing list mailing list archive at Nabble.com.
___
Gfoss@lists.gfoss.it
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.
750 iscritti al 18.3.2015

Re: [Gfoss] Sessione speciale sul GFOSS ad ASITA 2015

2015-07-24 Per discussione aperi2007

Ciao Stefano.

Scusa se ritorno sul titolo della sessione, ma la questione in effetti
incuriosisce il titolo e' intrigante.

Voi avete scritto:opportunita di sviluppo.

Sviluppo e' una parola che puo' avere piu' significati.
Immagino che non sia inteso nel senso di sviluppo del software, ma
piuttosto di crescita economica.

Il punto interrogativo, come ha puntualizzato Marco lo pone in formula
interrogativa e quindi presuppone di avere risposte. Secondo me anche
l'aggettivo reale rafforza la formula interrogativa.

Per cui il tema diviene parecchio impegnativo.
Non pensate che cosi' caricate la sessione di troppe aspettative ?

Il 24/07/2015 13:09, stefano campus ha scritto:

la domanda è retorica: la risposta sarà ovviamente affermativa

:-)

--
View this message in context:
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Sessione-speciale-sul-GFOSS-ad-ASITA-2015-tp7593245p7593261.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian
mailing list mailing list archive at Nabble.com.
___
Gfoss@lists.gfoss.it
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.
750 iscritti al 18.3.2015

Re: [Gfoss] Calcolo coordinate in una tabella Pgsql

2015-07-19 Per discussione aperi2007



Ciao,

non ho capito se ti riferisci a libreria di simboli per la Geologia.

Se e' cosi,
le trovi con tanto di simboli SVG.
Scaricando da cartoteca il pacchetto relativo al DBGeologico.

http://www502.regione.toscana.it/geoscopio/cartoteca.html
- download
- geologia
- Database Geologico Regionale.

O in alternativa lo cerchi attraverso il portale opendata di RT.

Una volta scaricato lo esplodi in una cartella , ma prima di lanciare il 
progetto qgis, devi assicurarti leggendo il pdf con le istruzioni di 
configurazione di aver settato correttamente i percorsi verso gli svg.


Se , come fanno tutti, lo apri senza aver configurato i percorsi 
correttamente.
Non solo non vedrai i simboli , ma tanti caratteri ? al loro posto , ma 
se poi dai retta  a qgis e salvi il progetto in uscita, te lo rovina 
irrimediabilmente .


A.

Il 11/07/2015 17:46, Alessandro Ciali ha scritto:


Sarei ben lieto di partecipare al miglioramento, a che non sono un 
genio della programmazione .a piuttosto un autodidatta coatto. Intanto 
scarichero' il tutto dal sito dell'ARPA per vedere se e come il mio 
lavoro possa integrare ciò che è stato fatto. Lavorando in parte nel 
campo della geologia per la pianificazione territoriale, ma lavorando 
prev. In toscana, ho sviluppato librerie di simboli che si attengono 
alle specifiche di questa regione; non mi sembra di aver trovato sul 
sito della RT librerie specifiche per QGIS, io le condividerei 
volentieri;  anzi visto che alcuni membri di RT partecipa a questa 
lista, potrebbero, se sono interessati, a darmi informazioni in 
merito. Per adesso grazie per le dritte, spero di poter contribuire. 
Saluti a tutti


Inviato da Samsung Mobile.


 Messaggio originale 
Da: Luca Lanteri
Data:11/07/2015 10:18 (GMT+01:00)
A: Alessandro Ciali
Cc: GFOSS.it
Oggetto: Re: Re: [Gfoss] Calcolo coordinate in una tabella Pgsql



Il giorno 10 luglio 2015 23:03, Alessandro Ciali 
alessandro.ci...@gmail.com mailto:alessandro.ci...@gmail.com ha 
scritto:


N..ma cosi è  finito il divertimento!!!

Allora meglio che non ti non ti mandi il link !
;-)

scherzi a parte, invece di reinventare la ruota, perché non 
contribuire ad un progetto già avviato, sarebbe sicuramente più 
proficuo per tutti.
Sono già state fatte le strutture dati in sqlite e postgres, la 
simbologia, gli allestimenti cartografici ed i form di inserimento dei 
dati utilizzando QGIS. Il tutto però è ancora ampliamente migliorabile.

Se sei interessato contattami pure quando vuoi.

Luca

p.s. facciamo così, invece di mandarti il link agli strumenti ti mando 
quello al post di alcuni mesi fa dove era stata comunicata la 
disponibilità degli strumenti per la MZS. Trovi anche altre cose 
interessanti se lavori nel campo della geologia. Ad esempio sulla 
parte di simbologia ci sarebbe parecchio da fare per creare librerie 
di simboli condivise, cosa su cui se non sbaglio anche Regione Toscana 
ha lavorato.

http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Strumenti-FOSS-per-la-geologia-td7592772.html

Inviato da Samsung Mobile.


 Messaggio originale 
Da: Luca Lanteri
Data:10/07/2015 22:58 (GMT+01:00)
A: aciali
Cc: GFOSS. it
Oggetto: Re: [Gfoss] Calcolo coordinate in una tabella Pgsql

Sul sito di arpa Piemonte trovi tutto gia belle che pronto!
Domani ti mando il link, adesso dal telefono non lo ho sottomano.

Il 08/Lug/2015 16:56, aciali alessandro.ci...@gmail.com
mailto:alessandro.ci...@gmail.com ha scritto:

Funziona! Grazie ancora, mi stavo incasinando la vita
inutilmente...

sto preparando un Db per l'archiviazione dei dati base in
linea con le
specifiche nazionali e regionali per la Microzonazione
Sismica, utilizzabile
tramite QGIS. Quando lo concluderò posterò il tutto, se
qualcuno ne avesse
bisogno mi farebbe piacere condividerlo.
Saluti



--
View this message in context:

http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Calcolo-coordinate-in-una-tabella-Pgsql-tp7593079p7593087.html
Sent from the Gfoss -- Geographic Free and Open Source
Software - Italian mailing list mailing list archive at
Nabble.com.
___
Gfoss@lists.gfoss.it mailto:Gfoss@lists.gfoss.it
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.
750 iscritti al 18.3.2015




___
Gfoss@lists.gfoss.it
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

Re: [Gfoss] R: R: Ridurre dimensione ed ottimizzazione tiff per webgis

2015-07-14 Per discussione aperi2007


Ciao,

il raster ha sicuramente senso che possa essere interrogabile.

In alcuni casi, li abbiamo messi interrogabili sui nostri servers wms.
Su mapserver la cosa e' possibile ed e' possibile personalizzare 
l'output, ad esempio facendogli ritornare il valore RGB, separatamente, 
oppure facendogli ritornare  il valore float.


Pensa al casoin cui servi con il wms un dato DTM come ascii-grid 
configurato a raster.
In tal caso ha perfettamente senso che il WMS a fronte di una 
interrogazione ritorni il valore della cella (intero o float che sia), 
che tipicamente corrisponderebbe alla quota sul punto clicckato.


Se vuoi un esempio puoi provare a collegarti con qgis al nostro server 
wms che propone il DTM10metri.

http://www502.regione.toscana.it/wmsraster/com.rt.wms.RTmap/wms?map=wmsmorfologia

Lo puoi vedere come elemento wms raster colorato (con le soglie previste 
dall'istat), se provi a interrogarlo, ti ritorna la quota del punto dove 
hai clicckato.


A.




Il 14/07/2015 17:54, Rossin Pietro ha scritto:

Messo sul server con lizmap va molto veloce, sono soddisfatto..

Per chi usa lizmap, si possono interrogare i raster?
Ho provato ad abilitare il popup, ma non mi compaiono valori cliccando la 
batimetria..


___
Gfoss@lists.gfoss.it
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.
750 iscritti al 18.3.2015

Re: [Gfoss] Pansharpening da immagini landsat

2015-06-12 Per discussione aperi2007


Ciao,
hai risposto a un dubbio che avevo da tempo.
Trovavo a giro un sacco di trattazioni sul pansharpening, ma nessun vero 
algoritmo.


Ho invece trovato qualche (una) utility che esegue il pansharpening.
https://github.com/developmentseed/landsat-util
Immagino che sia free.
Conto di provarla a brevissimo.

A.


Il 12/06/2015 23:42, Francesco P. Lovergine ha scritto:

On Fri, Jun 12, 2015 at 09:33:50PM +0200, a.furi...@lqt.it wrote:

battuta assolutamente mitica: me la segno a futura memoria perche' e'
perfettamente azzeccata :-D



e - per motivi per me inconprensibili - spesso patented, per cui non
ci sono implementazioni free.


scusami, e allora questi qua ?

http://grass.osgeo.org/grass70/manuals/i.pansharpen.html

parrebbe che almeno IHS, Brove e PCA siano patent-free, visto che
c'e' gia' chi li ha implementati sotto GPL


Si, si intendevo a parte quanto implementato in grass. La maggioranza
degli altri algoritmi (se non tutti) sono patented e i relativi paper
che non-descrivono gli algoritmii sono veramente curiosi da leggere.
Tutti sul tipo: ecco qua un nuovo algoritmo assolutamente figo, molto meglio
di quegli altri, ma non vi dico come è fatto, però queste sono
le immagini di esempio, dalle quali *ad occhio* si vede benissimo
quanto sia meglio di quegli altri. Roba da accappottarsi dalle risate.
Va beh, elucubrazione della sera...



___
Gfoss@lists.gfoss.it
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.
750 iscritti al 18.3.2015

Re: [Gfoss] Gestione di bad layers in QGIS

2015-05-13 Per discussione aperi2007


Nelle vecchie versioni di qgis.
Tutte le volte che si apriva un progetto, qgis faceva una copia del 
progetto stesso) identificabile con un tilde nella sua estensione.


Non so' se e' ancora presente. Se si, si puo' ricorrere a tale copia di 
backup per ripristinare il progetto altirmenti modificato 
irrimediabilmente.


A.


Il 13/05/2015 08:41, Alessandro Sarretta ha scritto:

Ciao a tutti,
quando in QGIS si apre un progetto, nel caso ci siano layer non 
raggiungibili (il path locale è cambiato, WMS o altri servizi quando 
si è offline, tabelle di DB quando non si è connessi al DB, ...) 
appare una finestra Handle bad layers che presenta il problema e 
permette di correggere.
Il grosso problema che vedo io è che se non si riassegnano i layer 
correttamente, essi vengono cancellati dal progetto. Questo è molto 
critico in progetti complessi... Un comportamento molto più 
ragionevole sarebbe quello di segnarli come unavailable o broken 
in legenda e poterli correggere in seguito, o lasciarli rotti...

Qui http://hub.qgis.org/issues/8718 l'issue è descritto bene.
I più informti sanno se qualcuno ci sta lavorando?
C'è qualche workaround (oltre che salvare il progetto con un altro 
nome prima di aprirlo :-)) da suggerire?

Grazie,

Ale


--

Alessandro Sarretta

skype/twitter: alesarrett
Web: ilsarrett.wordpress.com http://ilsarrett.wordpress.com

Research information:

  * Google scholar profile
http://scholar.google.it/citations?user=IsyXargJhl=it
  * ORCID http://orcid.org/-0002-1475-8686
  * Research Gate
https://www.researchgate.net/profile/Alessandro_Sarretta
  * https://impactstory.org/AlessandroSarretta



___
Gfoss@lists.gfoss.it
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.
750 iscritti al 18.3.2015


___
Gfoss@lists.gfoss.it
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.
750 iscritti al 18.3.2015

Re: [Gfoss] Traduzione QGIS

2015-04-28 Per discussione aperi2007


Salve,
io usualmente non intervengo sulla questione della documentazione 
perche' e' in effetti una cosa imbarazzante.


Chi lavora in un ente pubblico spesso , e' costretto a usare determinati 
softwares.
Penso ad esempio ai nostri colleghi. Molti di loro preferirebbero di 
gran lunga lavorare con ArcGIS e che vengono obbligati obtorto collo  
usare QGIS.

:)

Poi, pero' difficile chiedergli pure di contribuire volontaristicamente 
alla traduzione di qgis in italiano.


Per questo, tendo a tenermene in disparte.
Sicuramente se un bel giorno non saro' piu' un dipendente pubblico e 
avro' una libera professione che faccia uso dei GIS contribuiro' di mia 
spontanea volonta'.


Pero' una considerazione mi permetto di dirla:
io sono sempre stato poco propenso alla manualistica di qgis.
Qui centra poco inglese o italiano.

La manualistica in nglese e' abbastanza scadente e di conseguenza la 
traduzione in italiano che poveretta ha il vincolo di tradurre e basta e 
non correggere o aggiungere bei pezzi di spiegazioni fatte bene, finisce 
per essere scadente pure essa.
Ma non per colpa dei traduttori, ma perche' il materiale di partenza non 
è un granche'.


La regola generale e'che la traduzione in italiano non puo' integrare o 
aggiungere cose che quella in inglese non possiede.


Invece servirebbe che chi traduce , abbia la liberta' di integrare (nel 
manuale ovviamente) aggiungendo nuove e piu' ricche spiegazioni.


E anche a volte andare contro cio' che viene detto in quella in inglese.

cito ad esempio:
Dal manuale di qgis 2.6 in italiano:

*.

Creare un nuovo vettore SpatiaLite

Per creare un nuovo vettore SpatiaLite, fai riferimento alla sezione 
Creare un nuovo layer SpatiaLite.


Suggerimento

SpatiaLite data management plugin

Per la gestione dei dati SpatiaLite puoi usare diversi plugin: 
QSpatiaLite, SpatiaLite Manager o DB Manager (plugin nativo, 
raccomandato). Li puoi scaricare e installare con il gestore dei plugin.

Vettori Spatial

*




Se in unmanuale di qgis viene detto suggerimento: fai cosi' 
e' ovvio che l'utente percorre quella strada.
Ebbene nessuna di queste strade e' quella piu' corretta per lavorare con 
i dati in spatialite.
Intanto QSPatialite non esiste piu' da templ, non è stato piu' 
aggiornato etc..., db.manager ogni tanto genera tabelle incompatibili, 
il terzo manco lo conosco.


E invece l'unica strada che dovrebbe essre usata, ovvero il provider 
spatialite oppure in alternativa il driver OGR

non vengono citate.

Questo e' un vulnus forte della documentazione in inglese.

Si porta dietro vecchie magagne.

Poi , quella in italiano che non corregge, ma si limita a tradurre 
mantiene e consolida.


Per questo io sono sempre stato poco propenso a usare la manualistica di 
QGIS.


A questo punto, so' gi'a che mi verra' risposto:
Metti soldi e finanzia una revisione del mauale in inglese.

Ovviamente non posso farlo.
Quello che volevo dire e' che come community vi suggerirei che piuttosto 
che tenervi vincolati a supportare una taduzione del manuale in inglese, 
pensiate piuttosto a un manuale in italiano che partendo dai contenuti 
di quello in inglese consenta di allargare i discorsi , aggiungere nuovi 
capitoli, esempi, e corregga quanto di sbagliato vi e' in quelo inglese.


Il mio contributo in considerazioni termina qui.

Saluti,

A.


A.


Il 28/04/2015 06:56, Paolo Cavallini ha scritto:

Salve.

Ohbravi, cosi' vi riconosco :) ! Cerco di chiarire qualche punto.

* Grazie per i suggerimenti; mi pare evidente dalle risposte che:
   * non abbiamo intercettato il grosso degli utenti: qualcuno ha idea di
altri canali da utilizzare?
   * non e' stata evidente, ai partecipanti piu' attivi della lista,
l'importanza delle donazioni
* c'e' si preferisce usare gratis il lavoro di altri, e non si preoccupa
di contribuire quando ce n'e' bisogno
* distinguiamo fra:
   * *utenti singoli* - in questo caso capirei la reticenza a frugarsi in
tasca, invece sono sempre i maggiori donatori
   * *utenti professionali* - chi fa business con QGIS sarebbe logico si
garantisse una sua qualità, invece mi risulta facciano poco o (piu' che
altro) nulla
   * *enti* - un soggetto che usa QGIS come GIS principale o esclusivo
(ce ne sono ormai molti in Italia) che non si garantisce, per il suo
proprio interesse, di avere una interfaccia ed un manuale ben tradotto,
proprio non lo capisco
* con il sistema di traduzione attuale, e con l'esigenza di una versione
di lungo termine (che tanti hanno salutato con piacere, fin quando il
lavoro extra ricade sulle spalle altrui) e' necessaria una figura di
coordinamento, altrimenti si rischia di avere cartelle per il vino Non
me ne voglia l'autore della svista! ;) ). Purtroppo avere molti
volontari, se in piccola parte semplifica le cose, dall'altra rende il
coordinamento parecchio piu' complicato e faticoso.

Operativamente:
* chi puo' donare, doni
* anche chi non puo', ma lo ritiene utile per il proprio lavoro, faccia
il possibile per coinvolgere altri,

Re: [Gfoss] Fwd: [Discussioni] Le sette sorelle del software

2015-04-25 Per discussione aperi2007


Ciao Paolo,

NOn sono molto daccordo con l'impostazione del tuo ragionamento.
Capisco che probabilmente intendevi altro, il senso e' un po' differente.

Il punto dirimente non puo' essere che si deve finanziare prodotti 
italiani e ignorare quelli esteri.


Prendi ad esempio QGIS:
QGIS e' un progetto internazionale su cui mi pare di capire che L'italia 
non e' il maggiore contribuente, almeno se vado a vedere gli sponsor 
bronze/silver e gold. Sono quasi tutti esteri.
Cio' nonostante molti , anche in italia lo usano e immagino che qualcuno 
(probabilmente non tutti) sia anche soddisfatto di usarlo.
Noi stessi ci abbiamo investito per migliorarlo , seguendo anche le 
nostre necessita', quando ne avevamo la possibilita' e vi era una valida 
ragione legata ad aggiungere ad esso delle evoluzioni che ci servivano 
per i nostri lavori.
Ora che abbiamo meno disponibiltia' stiamo alla finestra e pero' taiamo 
beneficio degli investimenti fatti che nel tempo si vanno evolvendo 
grazie anche ai finanziamenti che arrivano da altre nazioni.


La tua obiazione va nella direzione di contestare anche questo nostro 
approccio.
Perche' se te dici che dovremmo puntare su progetti italiani, , stai 
dicendo che dovremmo alimentare i soliti orticelli che negli anni hanno 
creato delle rendite di fatto senza nessun beneficio specifico per la 
collettivita'.
Dico nessun vantaggio perche' se si dice che gli italiani devono 
finanziare progetti italiani, poi i francesi finanzieranno progetti 
francesi, gli svizzeri idem e i tedeschi non saranno da meno.
E allora si ritorna alle solite sabbie mobili che ci ha portato dove 
siamo oggi.


L'obiettivo a cui si deve tendere e' avere dei softwares GIS gfoss 
sempre migliori efficienti e con sempre meno difetti (a proposito del 
bacone galattico sui tfw di ieri...). I veri profitti per la comunita' 
delle perosne che lavorano con i GIS devono arrivare dal proprio lavoro, 
e se uno opera con i gis , avra' profitto se dispone di un software GIS 
valido efficiente e con sempre meno difetti. Certo ci sono anche quelli 
che di mestiere scrivono codice GIS, ma l'impiego di qgis che e' 
OpenSource va anche nella direzione di aprire una strada di lavoro anche 
a loro.
E anche li' pero' non puo' valere il principio che si da' a un italiano 
perche' e' italiano.

Si da' a un italiano perche' (e se ) e' bravo.

Saluti,

A.

Il 25/04/2015 07:29, Paolo Cavallini ha scritto:

Salve.
Una minianalisi interessante, e direi totalmente condivisibile.
Aggiungo, per il nostro settore, i 5 milioncini abbondanti di:
http://www.blia.it/appalti_pubblici/index.php?k=10135
(e ovviamente non è tutto qui), mentre qui i progetti, anche largamente
italiani, fanno fatica a racimolare qualche migliaio di euro.
Il prossimo amministratore / politico che mi viene a dire che dobbiamo
avere fiducia nelle capacita' del nostro paese, ho i numeri per
rispondergli: se per primi gli amministratori investono in competenze
estere piuttosto che in quelle italiane, cosa ci dobbiamo aspettare dal
futuro?
Saluti.

  Messaggio Inoltrato 
Oggetto: [Discussioni] Le sette sorelle del software
Data: Sat, 25 Apr 2015 00:19:27 +0200
Mittente: Antonio anton...@blia.it
Rispondi-a: Discussioni sul software libero. discussi...@softwarelibero.it
A: Discussioni sul software libero. discussi...@softwarelibero.it

Una volta nel petrolio c'erano le sette sorelle, ora ci sono nel software.
IBM, Oracle, Microsoft, SAP, Accenture, CA, Adobe in Italia fanno affari
d'oro.

Centinaia di milioni di euro che vanno verso l'estero quando si
potrebbero investire qui da noi (anche grazie al FOSS).

Alcuni esempi di appalti milionari? Eccoli:

IBM https://www.blia.it/appalti_pubblici/?k=13639 (senza parlare di
tutti quegli appalti in cui IBM fa parte di una rete di imprese, tipo
qui http://www.blia.it/appalti_pubblici/?k=10134 o qui
https://www.blia.it/appalti_pubblici/?k=10429 )

Oracle https://www.blia.it/appalti_pubblici/index.php?k=19425

Microsoft https://www.blia.it/appalti_pubblici/index.php?k=17921

SAP https://www.blia.it/appalti_pubblici/index.php?k=22515

Accenture https://www.blia.it/appalti_pubblici/index.php?k=411

ecc.

Molte di queste aziende fanno i soldi con i database, e in effetti a
guardare quante installazioni dei loro prodotti ci sono nella P.A. (v.
https://www.blia.it/db_pa/index.php ) la domanda, come direbbe qualcuno,
sorge spontanea.
Ma è davvero necessario un db Oracle ad un comune di neanche 7000
abitanti (Abbadia San Salvatore) per citarne uno, ma di casi del genere
ce ne sono a migliaia.

Voglio chiudere questa mail con una chiosa, in Italia abbiamo gente
brava e preparata, in grado di costruire cluster di DB (con Apache
Hadoop ad esempio) e altri che si inventano motori nuovi di DB NoSQL,
come ad esempio uno che conosco personalmente, Salvatore Sanfilippo, che
da solo (e successivamente con pochi altri) ha realizzato Redis (v.
http://redis.io/ ).
E la P.A. invece che fa? compra un Oracle da migliaia di euro per

Re: [Gfoss] [ot] Augmented Reality Sandbox - realtime topographic contour line generation

2015-04-08 Per discussione aperi2007


Veramente.
Le tecniche di simulazione per la modellistica stanno facendo passi da 
gigante.


Grazie per la segnalazione.

A.


Il 08/04/2015 18:34, stefano campus ha scritto:

decisamente spettacolare!!!

https://www.youtube.com/watch?v=Ki8UXSJmrJE
https://www.youtube.com/watch?v=g6fSS3cynDo

http://idav.ucdavis.edu/~okreylos/ResDev/index.html

s.




--
View this message in context: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/ot-Augmented-Reality-Sandbox-realtime-topographic-contour-line-generation-tp7592123.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian 
mailing list mailing list archive at Nabble.com.
___
Gfoss@lists.gfoss.it
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.
750 iscritti al 18.3.2015


___
Gfoss@lists.gfoss.it
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.
750 iscritti al 18.3.2015

Re: [Gfoss] Fwd: [Qgis-developer] QGIS GRASS Plugin Upgrade Crowdfunding

2015-03-23 Per discussione aperi2007


Ciao Paolo,


Per essere chiari: se si raggiunge l'obiettivo, si avrà l'aggiornamento,
altrimenti no.



Puoi spiegare meglio cosa sarebbe l'obiettivo ?
E' il nuovo plugin o e' uno dei 4 package in cui e' suddiviso ?

Leggendo sul sito di Radim:

This funding campaign is KiA model, it means that total goal has not 
to be reached.
The work is divided into more packages, which will be implemented if 
the amount of collected resources
reaches partial cumulative goal (set for each package). If the 
collected amount does not reach the total
goal, the packages with partial cumulative goal over the collected sum 
will be left not implemented.


A quello che capivo io si trattava di 4 moduli, ognuno con un proprio 
costo e che poteva essere realizzato oppure no in base al raggiungimento 
dell'obiettivo di finanziamento.


Oppure se non sono finanziati completamente tutti e 4 niente viene 
realizzato ?


A.



Il 23/03/2015 21:00, Paolo Cavallini ha scritto:

Salve.
Se qualcuno trova utile il plugin di GRASS entro QGIS, gli raccomando di
finanziarne l'aggiornamento a GRASS 7.
Radim offre le migliori garanzie per un lavoro a regola d'arte, essendo
l'inventore e lo sviluppatore del plugin.
Per essere chiari: se si raggiunge l'obiettivo, si avrà l'aggiornamento,
altrimenti no.
Saluti.

  Messaggio Inoltrato 
Oggetto: [Qgis-developer] QGIS GRASS Plugin Upgrade Crowdfunding
Data: Mon, 23 Mar 2015 19:56:39 +0100
Mittente: Radim Blazek radim.bla...@gmail.com
A: qgis-user List qgis-u...@lists.osgeo.org, qgis-developer
qgis-develo...@lists.osgeo.org, grass-u...@lists.osgeo.org,
grass-...@lists.osgeo.org grass-...@lists.osgeo.org

Hi all,

I have finally launched the crowdfunding campaign to support the GRASS
plugin upgrade. Briefly, it covers upgrade to GRASS 7, browser
integration, drag-and-drop import and new vector editing. All the
details are available here:

 http://www.gissula.eu/qgis-grass-plugin-crowdfunding/

Please propagate this info to all relevant channels, national mailing
lists etc.

Radim
___
Qgis-developer mailing list
qgis-develo...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


___
Gfoss@lists.gfoss.it
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.
750 iscritti al 18.3.2015


___
Gfoss@lists.gfoss.it
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.
750 iscritti al 18.3.2015

Re: [Gfoss] aprire sld con qgis

2015-03-01 Per discussione aperi2007

IL formato SLD pur essendo uno standard ha avuto uno sviluppo molto
sfortunato.

Ogni software che lo ha implementato ha pensato bene di interpretarlo a
modo suo.

Anche qgis non e' sfuggito a questa regola comportamentale.
Per cui l' SLD di qgis non credo che sia letto da Arcgis, come pure l'
SLD di arcgis non e' letto da qgis.

O meglio:
lo leggono, ma poi la meta' delle cose che ci stanno scritte non le
capisce o le capisce male e quindi non ti ritrovi cio' che ti aspetti di
vedere.

Ti va bene se conserva almeno i colori basici.
Le etichette direi che ci si possono scordare. Altre vestizioni piu'
coplesse (retinature e tratteggi) non vegono assolutamente comprese.

Non e' colpa ne' di uno ne' dell'altro.
E' il formato SLD che era troppo vago nel descrivere certe cose,
lasciando a ogni prodotto liberta' di intendere come descrivere cosa e
come riprodurre cosa.

Per cui direi che a oggi il colloquio tra qgis e arcgis e' impossibile.
Forse se usi vestizioni molto semplici e banali senza trasparenze o cose
complicate, puo' darsi che una sorta di mini dialetto a comune possa
saltar fuori.

Felice di essere smentito.

Il 01/03/2015 10:33, Marco ha scritto:

Problema inverso.
Ho preparato degli shp con QGIS e devo inviarli ad utenti (Regione) che
usano ArcGis.
Se gli invio anche il file SLD, riescono a vedere le vestizioni originali
che avevo imposto ai layer (riempimento, bordo, etichetta, ecc...) o si
perdono qualcosa?

--
View this message in context:
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/aprire-sld-con-qgis-tp7578158p7591635.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian
mailing list mailing list archive at Nabble.com.
___
Gfoss@lists.gfoss.it
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+40 iscritti al 5.6.2014

Re: [Gfoss] Disponibili come Open GeoData le ortofoto in scala 1:2.000 della Regione Toscana

2015-02-24 Per discussione aperi2007


E per giunta il pixel e' a 1 metro.

quindi non solo hai peggiorato la qualita' dell'immagine ma la hai pure 
ridotta di risoluzione.


A.

Il 24/02/2015 15:55, aperi2007 ha scritto:

Ma che stai dicendo ?

Il tuo TIF e' codificato come jpeg.
Vuoi confrontre un TIFF lossless con un tiff jpeg ?

Stai scherzando vero ?

A.

Il 24/02/2015 14:41, Sieradz ha scritto:

Permettimi di dissentire: la risoluzione 20 cm/px è dentro il worldfile
(vedi riga 1 e 4 del .TFW) e non dentro questi Tiff toscani, non 
essendo

veri Geotiff.




___
Gfoss@lists.gfoss.it
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+40 iscritti al 5.6.2014

Re: [Gfoss] Disponibili come Open GeoData le ortofoto in scala 1:2.000 della Regione Toscana

2015-02-24 Per discussione aperi2007


No, non hai abbassato la risoluzione.
Avevi omesso la georef. Raccontavi di Geotiff, ma poi hai messo in linea 
un tiff non georef. Quesot mi ha tratot in inganno.


Comunque tornando al discros della compressione non puoi confrontare la 
qualita' di un jpeg che e' Lossy con un tiff lossless.


Le immagini lossless permettono di fare molte piu' cose di quelle lossy.

Ovviamente un tiff lossless puo' sempre essere riportato  a un tiff 
lossy come hai fato te con un discorso ambiguo che lascia pensare che si 
tratti della stessa immagine.
Mentre invece un tiff lossy (quello che fai scaricare te) non è mai 
riconducibile all'originale  lossless.


Per questo facciamo scaricare il ossless.
Perche' ci teniamo a divulgare i dati VERI non quelli Alleggeriti.

A.

Il 24/02/2015 16:02, aperi2007 ha scritto:

E per giunta il pixel e' a 1 metro.

quindi non solo hai peggiorato la qualita' dell'immagine ma la hai 
pure ridotta di risoluzione.


A.

Il 24/02/2015 15:55, aperi2007 ha scritto:

Ma che stai dicendo ?

Il tuo TIF e' codificato come jpeg.
Vuoi confrontre un TIFF lossless con un tiff jpeg ?

Stai scherzando vero ?

A.

Il 24/02/2015 14:41, Sieradz ha scritto:

Permettimi di dissentire: la risoluzione 20 cm/px è dentro il worldfile
(vedi riga 1 e 4 del .TFW) e non dentro questi Tiff toscani, non 
essendo

veri Geotiff.






___
Gfoss@lists.gfoss.it
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+40 iscritti al 5.6.2014

Re: [Gfoss] Disponibili come Open GeoData le ortofoto in scala 1:2.000 della Regione Toscana

2015-02-24 Per discussione aperi2007


Ma che stai dicendo ?

Il tuo TIF e' codificato come jpeg.
Vuoi confrontre un TIFF lossless con un tiff jpeg ?

Stai scherzando vero ?

A.

Il 24/02/2015 14:41, Sieradz ha scritto:

Permettimi di dissentire: la risoluzione 20 cm/px è dentro il worldfile
(vedi riga 1 e 4 del .TFW) e non dentro questi Tiff toscani, non essendo
veri Geotiff.


___
Gfoss@lists.gfoss.it
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+40 iscritti al 5.6.2014

Re: [Gfoss] colore etichetta

2015-01-24 Per discussione aperi2007


Non ho idea come funziona l'altlante.
Ti consiglio di girare le tue domande alla lista gfoss.
(in questo caso la giro io)

In questo modo hai occasione di condividere le tue esperienze e le 
scelte che hai fatto, nonche' di ricevere aiuto da chi conosce una 
specifica informazione.


Saluti,
A.

Il 24/01/2015 23:34, Totò Fiandaca ha scritto:
questa procedura funziona bene se devossi etichettare un vettore, ma 
come fare a cambiar colore dell'etichetta nell'atlante?


Il giorno 24 gennaio 2015 23:25, Totò Fiandaca 
pigrecoinfin...@gmail.com mailto:pigrecoinfin...@gmail.com ha scritto:


funziona bene!!!

Il giorno 24 gennaio 2015 23:23, Totò Fiandaca
pigrecoinfin...@gmail.com mailto:pigrecoinfin...@gmail.com ha
scritto:

no, ma sto provando questo quello di questo link:
http://mapfreely.org/2014/04/30/qgis-conditional-labeling/

Il giorno 24 gennaio 2015 23:20, aperi2007
aperi2...@gmail.com mailto:aperi2...@gmail.com ha scritto:

Questa qui la avevi gia' vista ?
http://www.qgis.org/it/docs/index.html#26

A.


Il 24/01/2015 23:05, Totò Fiandaca ha scritto:

il problema è tutto qua, esiste una manualistica? se si,
dova posso trovarla?


Il giorno 24 gennaio 2015 22:56, aperi2007
aperi2...@gmail.com mailto:aperi2...@gmail.com ha
scritto:

nelle proprieta' dentro la pagine delle etichette.
Se vai nella linguetta denominata Testo alla voce
colore vedi sulla destra una iconcina.
Se la cliccki ti apre un menu in cui puoi indicare il
nome del campo di riferiemtno.
Pero' se cliccki sulla voce modifica ti apre una
finestra dove puoi inserire una espressione.

Li' puoi provare a inserire una espressione
condizionata con un IF ELSE (cerca nella manualistica
i dettagli di come fare).

Non è detto che funzioni, ma vale la pena provare.

Andrea.


Il 24/01/2015 22:40, Totò Fiandaca ha scritto:

Come faccio a dare un colore ad un attributo (in
fase di etichettatura) di campo in funzione del
valore che assume?
mi spiego meglio, ho un campo con valori testuali e
vorrei colorarlo quando assume un particolare valore:
es: se il campo assume il valore '*ok*' nero, se
assume il valore '*ko*' rosso!
è possibile farlo pure in grassetto?

grazie!
-- 
*Salvatore Fiandaca*

*mobile*.:+39 327.493.8955 tel:%2B39%20327.493.8955
*m*: *pigrecoinfin...@gmail.com
mailto:pigrecoinfin...@gmail.com*



___
Gfoss@lists.gfoss.it  mailto:Gfoss@lists.gfoss.it
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+40 iscritti al 5.6.2014



___
Gfoss@lists.gfoss.it mailto:Gfoss@lists.gfoss.it
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+40 iscritti al 5.6.2014




-- 
*Salvatore Fiandaca*

*mobile*.:+39 327.493.8955 tel:%2B39%20327.493.8955
*m*: *pigrecoinfin...@gmail.com
mailto:pigrecoinfin...@gmail.com*






-- 
*Salvatore Fiandaca*

*mobile*.:+39 327.493.8955 tel:%2B39%20327.493.8955
*m*: *pigrecoinfin...@gmail.com
mailto:pigrecoinfin...@gmail.com*




-- 
*Salvatore Fiandaca*

*mobile*.:+39 327.493.8955 tel:%2B39%20327.493.8955
*m*: *pigrecoinfin...@gmail.com mailto:pigrecoinfin...@gmail.com*




--
*Salvatore Fiandaca*
*mobile*.:+39 327.493.8955
*m*: *pigrecoinfin...@gmail.com mailto:pigrecoinfin...@gmail.com*



___
Gfoss@lists.gfoss.it
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+40 iscritti al 5.6.2014

Re: [Gfoss] colore etichetta

2015-01-24 Per discussione aperi2007


Questa qui la avevi gia' vista ?
http://www.qgis.org/it/docs/index.html#26

A.


Il 24/01/2015 23:05, Totò Fiandaca ha scritto:
il problema è tutto qua, esiste una manualistica? se si, dova posso 
trovarla?



Il giorno 24 gennaio 2015 22:56, aperi2007 aperi2...@gmail.com 
mailto:aperi2...@gmail.com ha scritto:


nelle proprieta' dentro la pagine delle etichette.
Se vai nella linguetta denominata Testo alla voce colore vedi
sulla destra una iconcina.
Se la cliccki ti apre un menu in cui puoi indicare il nome del
campo di riferiemtno.
Pero' se cliccki sulla voce modifica ti apre una finestra dove
puoi inserire una espressione.

Li' puoi provare a inserire una espressione condizionata con un IF
ELSE (cerca nella manualistica i dettagli di come fare).

Non è detto che funzioni, ma vale la pena provare.

Andrea.


Il 24/01/2015 22:40, Totò Fiandaca ha scritto:

Come faccio a dare un colore ad un attributo (in fase di
etichettatura) di campo in funzione del valore che assume?
mi spiego meglio, ho un campo con valori testuali e vorrei
colorarlo quando assume un particolare valore:
es: se il campo assume il valore '*ok*' nero, se assume il valore
'*ko*' rosso!
è possibile farlo pure in grassetto?

grazie!
-- 
*Salvatore Fiandaca*

*mobile*.:+39 327.493.8955 tel:%2B39%20327.493.8955
*m*: *pigrecoinfin...@gmail.com mailto:pigrecoinfin...@gmail.com*



___
Gfoss@lists.gfoss.it  mailto:Gfoss@lists.gfoss.it
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+40 iscritti al 5.6.2014



___
Gfoss@lists.gfoss.it mailto:Gfoss@lists.gfoss.it
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+40 iscritti al 5.6.2014




--
*Salvatore Fiandaca*
*mobile*.:+39 327.493.8955
*m*: *pigrecoinfin...@gmail.com mailto:pigrecoinfin...@gmail.com*



___
Gfoss@lists.gfoss.it
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+40 iscritti al 5.6.2014

Re: [Gfoss] colore etichetta

2015-01-24 Per discussione aperi2007


nelle proprieta' dentro la pagine delle etichette.
Se vai nella linguetta denominata Testo alla voce colore vedi sulla 
destra una iconcina.
Se la cliccki ti apre un menu in cui puoi indicare il nome del campo di 
riferiemtno.
Pero' se cliccki sulla voce modifica ti apre una finestra dove puoi 
inserire una espressione.


Li' puoi provare a inserire una espressione condizionata con un IF ELSE 
(cerca nella manualistica i dettagli di come fare).


Non è detto che funzioni, ma vale la pena provare.

Andrea.


Il 24/01/2015 22:40, Totò Fiandaca ha scritto:
Come faccio a dare un colore ad un attributo (in fase di 
etichettatura) di campo in funzione del valore che assume?
mi spiego meglio, ho un campo con valori testuali e vorrei colorarlo 
quando assume un particolare valore:
es: se il campo assume il valore '*ok*' nero, se assume il valore 
'*ko*' rosso!

è possibile farlo pure in grassetto?

grazie!
--
*Salvatore Fiandaca*
*mobile*.:+39 327.493.8955
*m*: *pigrecoinfin...@gmail.com mailto:pigrecoinfin...@gmail.com*



___
Gfoss@lists.gfoss.it
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+40 iscritti al 5.6.2014


___
Gfoss@lists.gfoss.it
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+40 iscritti al 5.6.2014

Re: [Gfoss] Formato per il pubblico

2015-01-21 Per discussione aperi2007


Non credo che lo stato ti costringa.

Te puoi usare qualsiasi strumento vuoi e lavorare come vuoi.

Pero' , quando lo stato fa una gara e chiede al fornitore di fare le 
cose in un certo modo .

Il discorso cambia diviene un rapporto cliente / fornitore.

Li' non e' piu' lo stato che costringe.
Perche' non lo fai gratis , ma retribuito.

A.

Il 21/01/2015 16:28, GEOgrafica ha scritto:

Il giorno 21/gen/2015, alle ore 13:26, Nicola Marchesin 
kiefer.li...@gmail.com ha scritto:


A necessità virtù? Non era una frase da grandi meditazioni. Pensavo si capisse 
al volo, perdonami.
Se lo stato costringesse ogni amministrazione pubblica ad usare odf
anche i più imbranati come me imparerebbero ad usare gli odf e i relativi 
software per gestirli.
Se lo stato costringesse ogni amministrazione pubblica ad usare i .docx
anche i più imbranati come me imparerebbero ad usare i .docx

Io personalmente non vorrei vivere in uno stato dove lo stato mi COSTRINGE ad 
usare alcunché. Sia che si parli di robe  proprietarie o open.
Lo stato etico (che presuppone di imporre una certa etica ben precisa ai cittadini, 
meglio certe scelte definite a priori come “migliori) ha già dato ampi esempi 
di cattivo funzionamento nel Novecento, anche se qui si parla solo di GIS e non di 
ideologie totalitarie preferisco comunque avere sempre la possibilità di scegliere.

ciao
Marco

Marco Gualdrini
GEOgrafica - Faenza

---
GEOgrafica - GIS, cartografia digitale e simulazioni territoriali virtuali
www.geografica.org

Virtual Terrain Project / GeoView examples:
http://youtu.be/qEeGjNvwl4Y
http://youtu.be/9UPfufPLQUw
http://youtu.be/gv8HgX9TZfs

---

___
Gfoss@lists.gfoss.it
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+40 iscritti al 5.6.2014


___
Gfoss@lists.gfoss.it
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+40 iscritti al 5.6.2014

Re: [Gfoss] URGENTISSIMO! PS TIME - errore

2015-01-19 Per discussione aperi2007


Su Linux questo limite non esiste ?

Forse un po' piu' alto ?

A.


Il 19/01/2015 18:56, Paolo Cavallini ha scritto:

Il 19/01/2015 18:51, andrea.scaglia ha scritto:

Dimenticavo...
il vecchio nome è, per fare un esempio di uno sui dieci file:
Bardonecchia_DESC_HI_03_PSP_IFSAR_vel_medie_filtered
quello nuovo
DESC2_FILTR

credo tu sia incappata nel limite di lunghezza del nome dei files (o
percorsi, uno dei trojaj di windoz.
saluti.



___
Gfoss@lists.gfoss.it
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+40 iscritti al 5.6.2014

Re: [Gfoss] caricare vettoriali SL su geopaparazzi

2015-01-13 Per discussione aperi2007

Ciao,

il bug quale era ?

il merging dei multipoligoni creava una geometria Polygon ?

Mancava l' ST_Multi per forzare la risposta MultiPolygon ?.

Il 14/01/2015 08:17, andrea antonello ha scritto:

Noi siamo già pronti per l'upgrade ;-)

Ebbene sia! :-)

http://jgrasstechtips.blogspot.it/2015/01/geopaparazzi-almost-only-bugfix-release.html

Fammi sapere se risolve il tuo problema.

Andrea

--
View this message in context:
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/caricare-vettoriali-SL-su-geopaparazzi-tp7591041p7591116.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian
mailing list mailing list archive at Nabble.com.
___
Gfoss@lists.gfoss.it
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+40 iscritti al 5.6.2014

Re: [Gfoss] OpenData geografici - casi di successo basati sul loro impiego cerc

2014-11-22 Per discussione aperi2007


Grazie dei links,

mi sto studiando la genesi del progetto.
Mi pare di capire che comunque un organismo nazionale che ha fatto da 
catalizzatore del progetto vie' stato.
E su un singo progetto (iMove) si è formata una partnership di piu' 
soggetti.
Di cui uno  di essi ha il compito di distribuire i servizi a tutti gli 
altri partner e anche a soggetti esterni.

compresi eventuali utilizzatori per altri servizi.

Perquesto hanno messo in piedi una API e una infrastruttura di servizio.

Sono riuscito a trovare la pagina dei prezzi:
https://developer.transportapi.com/pricing

Da cui si vede che fino a 30.000 contatti al mese e' gratuita.
Oltre ha un set di prezzi decrescente.
In fondo alla pagin specificano anche alcune regole su cosa intendono 
per singolo contatto.


Un privato puo' anche scegliere forme differenti di contratto:
piano per contatti e pian per partnership.

Venendo alla parte tecnica, piu' interessante per poter capire chentipi 
di servizi forniscono:


Gestione dell'autentificazione sulla piattaforma
Informazioni sui BUS 
(https://developer.transportapi.com/documentation/bus-information)
Informazioni sulla metropolitana 
(https://developer.transportapi.com/documentation/tube-information)
Informazioni sul treno 
(https://developer.transportapi.com/documentation/train-information)
Routing multilivello con impiego di piu' mezzi pubblici 
(https://developer.transportapi.com/documentation/public-journey-planning)
Routing multilivello con impiego di mezzi di trasporto privati 
(https://developer.transportapi.com/documentation/private-journey-planning)


E forniscono pure delle widgets per mettere su pagine internet in iframe.

https://developer.transportapi.com/documentation/widgets


Quindi facilitano in ogni modo l'imiego dei loro servizi, puntando 
appunto sul servizio.

Ovvero sulla fornitura di informazioni sugli orari, percorsi.

Ovvio che tutto deve essere organizzato e l'informazione deve pervenire 
in tempo reale altrimenti tutto questo non serve a niente.


Ovviamente cio' che deve essere in temporeale e' l'informazione 
alfanumerica associata alla compoenente cartografica.
Leggi: orari dei mezzi, eventuali strade o percorsi interrotti per 
eventi improvvisi o programmati.

Eventuali cambi di direzione del flusso del traffico.

La cartografia di base e' la stessa. Ovviamente deve essere buona, ma 
qui si lavora sui grafi stradali (forse i civici , ma non e' detto che 
gli servano) e quindi e' un po' piu' facile (non facile in assoluto, ma 
un po' meno difficile del resto) .


Posso immaginare che alla base ci sia stato un appalto per la gestione 
del servizio di trasporto pubblico integrato che ha permesso a un 
soggetto di potersi organizzare e strutturare con delle partnerships che

hanno ricvi solo dalla fornitura di questi servizi.
Probabilmente questa ditta fornisce servizi alla stessa azienda che 
gestisce il trasporto vero e proprio.
DOpodiche' e' naturale che allarga la base di clienti mettendo a 
dispsizione delle API facili e rapide da usare.
In modo da avere ulteriori clienti. Non solo il soggetto che gestisce il 
trasporto.


Questo direi che e' un buon esempio di come si crea valore mettendo a 
disposizione servizi.
Peccato che non sono riuscito a trovare alcuna pagina che parla di 
fatturato della ditta.


Pero' e' evidente che il fatturato deriva primariamente dal contratto 
con i gestori dei servizi pubblici (non so' se metro, treni , trasporti 
su gomma) sono gestiti da uno o piu' soggetti immagino che siano piu' di 
uno.


In ogni caso che sia uno o molti, il concetto di mettere i dati del 
trasporto in mano a una ditta differente che trae sostentamento dalla 
vendita dei servizi basati su quei dati e' l'elemento centrale.
Se il gestore avesse fatto incasa, per lui vendere servizi all'estenro 
avrebbe voluto dire solo fastidio e con la cessazione del contratto , 
probabilmente un nuovo gestore avrebbe inventaot una piattaforma differente.


Invece una ditta diversa aiuta a tenere il servizio su una piattaforma 
neutra, trasversale e interoperabile.


Una ultima nota:
questo e' un caso di uso inglese su dati del grafo stradale e dei trasporti.

Il fatto che anche in Francia, si sono mossi dei soggetti privati (OSM 
francia) per realizzare un DB nazionale degli indirizzi e mettere in 
piedi una offerta di servizi su di esso.


Testimonia che sui dati del grafo stradale, sugli indirizzi e sugli 
orari dei mezzi di trasporto e' possibile creare valore dai servizi.


Ma a parte questa branca il resto della cartografia, riesce a creare 
valore ?


Infatti, come dicevo tendo a non considerare questi dei veri e propri 
dati geografici.
Intesi come percorso di una strada, di un fiume, morfologia del terreno, 
edificato. antropizzazione del territorio.


L'unica cosa che piu' si avvicina a un dato geografico e' l'informazione 
dell'interruzione di una strada, ma non piu' di tanto.


Lo dimostra l'approccio seguito nel dato che forniscono.
La georeferenziazione e' indiretta.

Re: [Gfoss] Metadati RNDT estensione della specifica e foglio excel per generare schede RNDT

2014-11-09 Per discussione aperi2007

toc toc
:)

Il 08/11/2014 20:41, aperi2007 ha scritto:

Abbastanza chiaro.

Pero' questo presuppone comunque che ci sia un namepsace codificato
per poterlo inserire in quella url che deve rappresentare una codifica
esistente.

http://www.opengis.net/def/crs/EPSG/0/4936 -- epsg:4326

Io non credo di poter scrivere
http://www.opengis.net/def/crs/RNDT/0/ROMA40
http://www.opengis.net/def/crs/EPSG/0/4936

a meno che RNDT non sia un codespace codificato a livello internazionale.

Pero' se capisco la tua spiegazione,
siccome il problema nasce solo quando si condivide i dati a livello
europeo.
Al momento della condivisione, il dato non sara' piu' roma40 perhe'
viene giocoforza convertito in un altro sistema di riferimento (ad
esempio: epsg:3003) e quindi a quel punto il problema di come
esprimerlo e' risolto perche' diventerebbe
http://www.opengis.net/def/crs/EPSG/0/3003
http://www.opengis.net/def/crs/EPSG/0/4936

il ragionamento non fa una grinza.

Quindi la codifica e' per le schede interne italiane e accompagnano i
dati che circolano in italia.
Mentre i dati che vanno all'estero vengono convertiti in altri sistemi
di riferimento piu' agili a livello internazionale e di conseguenza le
schede per l'estero vengono redatte con la codifica che mi hai indicato.

Spero di aver capito bene.

Il 08/11/2014 19:26, Piergiorgio Cipriano ha scritto:

Ciao,
corretto, all'estero non sanno cosa è ROMA40/OVEST.
Ecco perché in Inspire hanno previsto che i dati armonizzati abbiano,
come elementi aggiuntivi di interoperability, i valori espressi con
URI tipo http://www.opengis.net/def/crs/EPSG/0/4936

Questo lo trovi in ciascun documento di data specification, per
esempio quello su Administrative Units a pag. 60:

http://inspire.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_AU_v3.1.pdf

Gli elementi aggiuntivi di cui parlavo sopra sono quelli elencati a
pag.95 del documento:

http://inspire.ec.europa.eu/documents/Metadata/MD_IR_and_ISO_20131029.pdf

Re: [Gfoss] Quale formato?

2014-11-09 Per discussione aperi2007


Visto che si parte dal punto di vista che lo shp non è un buon formato.

Sicuramente un buon modo di procedere potrebbe essere quellodi elencare 
le sue manchevolezze.

Almeno si ha un termine di paragone con altri formati.

Eviterei infatti di scegliere un formato che oi alla prova dei fatti si 
potrebbe dimostrare peggiore di quello che si lascia.


Come contributo io fornisco la mia disamina:

esri shapefile:
.)non prevede l'indicazione del CharacterSet
.)e' limitato nella dimensione del record
.)limita di 10 caratteri al nome di un campo
.)non supporta geometrie complesse (solamente punti linee e poligoni, 
simple e multi)

.)ha un limite di 2GB per la parte alfanumerica (file dbf)
.)ha un limite di 2 GB per la parte geometrica
.)le geometrie sono in doppia-precisione
.)non possiede l'indicazione del NULL nei valori alfanumerici
.)non ha standardizzato l'indice spaziale
.)la presenza di formati leggermene difformi sul dbf impatta anche sullo 
shapefile
.)la separazione fisica tra shp e dbf fa' si' che un eiditng separato 
(mediante excel ad esempio) del dbf provoca la perdita del link con la 
geometria corrispondente


dimentico qualcosa ?

Saluti,

A.

Il 09/11/2014 12:26, Paolo Cavallini ha scritto:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Salve.

Siamo credo tutti d'accordo che shp non e' un buon formato, da molti
se non tutti i punti di vista. La nascita e la standardizzazione del
GeoPackage aveva dato speranze di trovare un efficace sostituto, ma il
tempo e' passato, e non pare che molto sia cambiato:

http://jamesfee.us/post/101781709416/nearly-2-years-ago-you-were-praising-geopackage-as-a

La questione: a questo punto, cosa e' piu' opportuno usare, sia per
l'uso normale che per la condivisione? Forse GeoJSON?
Pareri?

Saluti.
- -- 
Paolo Cavallini - www.faunalia.eu

QGIS  PostGIS courses: http://www.faunalia.eu/training.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlRfT3kACgkQ/NedwLUzIr5zFgCeLLo9BudHwZ0jW8+IgI50bnv3
oNMAoKnJVZyE2MOwnqzxEXN3posVmD2J
=W+OM
-END PGP SIGNATURE-
___
Gfoss@lists.gfoss.it
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+40 iscritti al 5.6.2014


___
Gfoss@lists.gfoss.it
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+40 iscritti al 5.6.2014

Re: [Gfoss] Metadati RNDT estensione della specifica e foglio excel per generare schede RNDT

Quindi si trattava di una serie di frasi preconfezionate da apporre in
un campo a testo libero.

mi torna .

Mi viene in mente un altro caso in cui ho visto una cosa analoga.

Nel profilo ESRI di ISO19115.
In tal caso esri ha usato il campo
applicationschema di tipo testuale libero dove ci andava una
descrizione testuale dell'application schema

per metterci in forma codificata a testo strutturato la definizione
degli attributi con i loro nomi, tipi e dimensioni.

E' una tecnica intelligente e perfettamente lecita per codificare
informazioni strutturate senza dover fare ricorso alla estensione delle
classi che citavo.

Grazie
della spiegazione.

Il 08/11/2014 17:36, Piergiorgio Cipriano ha scritto:

No, state sbagliando.

Il tag MD_ReferenceSystem è previsto dallo standard ISO19115, e
nella sua rappresentazione XML è qualcosa del genere:

gmd:MD_ReferenceSystem
gmd:referenceSystemIdentifier
gmd:RS_Identifier
gmd:code
gco:CharacterString.../gco:CharacterString
/gmd:code
/gmd:RS_Identifier
/gmd:referenceSystemIdentifier
/gmd:MD_ReferenceSystem

RNDT ha solo previsto che anziché valorizzare quel tag con una
semplice stringa (gco:CharacterString) si faccia riferimento ad una
lista di valori predefiniti.

Niente di più, niente di meno di quanto è stato fatto a livello
INSPIRE, per metadati di dati conformi alle Data Specification dei
vari temi, dove (Data Specification) potete trovare la lista di valori
EPSG, da valorizzare come URI.

Quindi RNDT *non *è fuori standard né ha fatto estensioni.
Se fosse andato fuori standard o se avesse fatto estensioni, i
metadati raccolti in RNDT non sarebbero stati validati da JRC come già
raccontato tempo fa:

- http://aborruso.github.io/it4insp/
-
http://inspire-geoportal.ec.europa.eu/resources/sandbox/INSPIRE-dc160d85-7f54-11e3-9486-d8d3855bd8fc_20140117-095358/services/1/PullResults/

pg
__
Piergiorgio Cipriano
https://twitter.com/PgCipriano

Il giorno 08 novembre 2014 16:55, a.furi...@lqt.it
mailto:a.furi...@lqt.it ha scritto:

On Sat, 8 Nov 2014 16:02:07 +0100, Andrea Peri wrote:

Salve,

Reputo interessante condividere anche questo dettaglio , sempre
relativo alla scheda di metadato ISO19115.

Dando una occhiata al documento della struttura RNDT per
confrontare
le traduzioni con quelle di qsphere,
mi e' caduto l'occhio sulla codelist MD_ReferenceSystemCode
descritta
al paragrafo 3.4.3.11 del documento RNDT:

http://www.rndt.gov.it/RNDT/home/images/struttura/documenti/DM_RNDT.pdf

Non ne riesco a trovare traccia nella specifica ISO 19115 in
relazione
alla sezione dei sistemi di riferimento.
Nelle specifiche SIO trovo la classe MD_ReferenceSystem , ma
non trovo
la MD_ReferenceSystemCode.

Per cui la prima cosa che posso pensare e' che questa codelist non
faccia parte della specifica ISO.

Andrea,

almeno a prima vista quel tag MD_ReferenceSystemCode parrebbe
proprio
un'estensione fuori standard esclusivamente italiana.
cercando sul web le uniche citazioni che sono riuscito a trovare per
quel tag sono solo ed esclusivamente in documenti in lingua italiana
(stato, regioni, cnr etc)

comunque qua ci trovi un chiarimento sicuramente utile:

http://www.rndt.gov.it/RNDT/home/images/RNDT_guida_operativa_dati_v2.0_20140725.pdf

al paragrafo 2.1.4.2 lo dice esplicitamente che Elemento INSPIRE:
nessun elemento corrispondente, e cita un riferimento diretto
all'allegato 2 del DM 10 novembre 2011

ciao Sandro

___
Gfoss@lists.gfoss.it mailto:Gfoss@lists.gfoss.it
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+40 iscritti al 5.6.2014

Re: [Gfoss] Metadati RNDT estensione della specifica e foglio excel per generare schede RNDT


Ciao Alessandro,

Si tale codelist non e' prevista esplicitamente da ISO,
ma come dicevo,  ISO permette di estendere la specifica aggiungendo 
classi nuove e codelist nuove.
Basta che chi lo fa' aggiunga nel xml le descrizioni di tali classi 
secondo una regole codificata in ISO19115 stesso.


Certo poi occorre supportarlo e questo e' un altro paio di maniche.

Comunque non e' il nostro caso.
Infatti la risposta di Cipriano spiega tutto.

A.

Il 08/11/2014 16:55, a.furi...@lqt.it ha scritto:

On Sat, 8 Nov 2014 16:02:07 +0100, Andrea Peri wrote:

Salve,

Reputo interessante condividere anche questo dettaglio , sempre
relativo alla scheda di metadato ISO19115.

Dando una occhiata al documento della struttura RNDT per confrontare
le traduzioni con quelle di qsphere,
mi e' caduto l'occhio sulla codelist MD_ReferenceSystemCode descritta
al paragrafo 3.4.3.11 del documento RNDT:


http://www.rndt.gov.it/RNDT/home/images/struttura/documenti/DM_RNDT.pdf

Non ne riesco a trovare traccia nella specifica ISO 19115 in relazione
alla sezione dei sistemi di riferimento.
Nelle specifiche SIO trovo la classe MD_ReferenceSystem , ma non trovo
la MD_ReferenceSystemCode.

Per cui la prima cosa che posso pensare e' che questa codelist non
faccia parte della specifica ISO.



Andrea,

almeno a prima vista quel tag MD_ReferenceSystemCode parrebbe proprio
un'estensione fuori standard esclusivamente italiana.
cercando sul web le uniche citazioni che sono riuscito a trovare per
quel tag sono solo ed esclusivamente in documenti in lingua italiana
(stato, regioni, cnr etc)

comunque qua ci trovi un chiarimento sicuramente utile:

http://www.rndt.gov.it/RNDT/home/images/RNDT_guida_operativa_dati_v2.0_20140725.pdf 



al paragrafo 2.1.4.2 lo dice esplicitamente che Elemento INSPIRE:
nessun elemento corrispondente, e cita un riferimento diretto
all'allegato 2 del DM 10 novembre 2011

ciao Sandro



___
Gfoss@lists.gfoss.it
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+40 iscritti al 5.6.2014


___
Gfoss@lists.gfoss.it
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+40 iscritti al 5.6.2014

Re: [Gfoss] Metadati RNDT estensione della specifica e foglio excel per generare schede RNDT


Ciao Alessandro,

Si tale codelist non e' prevista esplicitamente da ISO,
ma come dicevo,  ISO permette di estendere la specifica aggiungendo 
classi nuove e codelist nuove.
Basta che chi lo fa' aggiunga nel xml le descrizioni di tali classi 
secondo una regole codificata in ISO19115 stesso.


Certo poi occorre supportarlo e questo e' un altro paio di maniche.

Comunque non e' il nostro caso.
Infatti la risposta di Cipriano spiega tutto.

A.

Il 08/11/2014 16:55, a.furi...@lqt.it ha scritto:

On Sat, 8 Nov 2014 16:02:07 +0100, Andrea Peri wrote:

Salve,

Reputo interessante condividere anche questo dettaglio , sempre
relativo alla scheda di metadato ISO19115.

Dando una occhiata al documento della struttura RNDT per confrontare
le traduzioni con quelle di qsphere,
mi e' caduto l'occhio sulla codelist MD_ReferenceSystemCode descritta
al paragrafo 3.4.3.11 del documento RNDT:


http://www.rndt.gov.it/RNDT/home/images/struttura/documenti/DM_RNDT.pdf

Non ne riesco a trovare traccia nella specifica ISO 19115 in relazione
alla sezione dei sistemi di riferimento.
Nelle specifiche SIO trovo la classe MD_ReferenceSystem , ma non trovo
la MD_ReferenceSystemCode.

Per cui la prima cosa che posso pensare e' che questa codelist non
faccia parte della specifica ISO.



Andrea,

almeno a prima vista quel tag MD_ReferenceSystemCode parrebbe proprio
un'estensione fuori standard esclusivamente italiana.
cercando sul web le uniche citazioni che sono riuscito a trovare per
quel tag sono solo ed esclusivamente in documenti in lingua italiana
(stato, regioni, cnr etc)

comunque qua ci trovi un chiarimento sicuramente utile:

http://www.rndt.gov.it/RNDT/home/images/RNDT_guida_operativa_dati_v2.0_20140725.pdf 



al paragrafo 2.1.4.2 lo dice esplicitamente che Elemento INSPIRE:
nessun elemento corrispondente, e cita un riferimento diretto
all'allegato 2 del DM 10 novembre 2011

ciao Sandro



___
Gfoss@lists.gfoss.it
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+40 iscritti al 5.6.2014


___
Gfoss@lists.gfoss.it
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+40 iscritti al 5.6.2014

Re: [Gfoss] Metadati RNDT estensione della specifica e foglio excel per generare schede RNDT


Ciao PG,
grazie per le spiegazioni.

Ti sfrutto perun dettaglio tecncio che non ho mai compreso appieno.

Allego una immagine tratta da ISO19115.
per spiegare meglio:


dalla specifica ISO19115 vedo che code e' l'unico obbligatorio ed e' 
sito sotto MD_Identifier.


mentre sotto RS_Identifier ci sarebbero
codespace e version.

Nel tuo esempio
te usi RS_Identifier pero' lo popoli solo con code.

Immagino che sia lecito perche' RS_Identifier estende MD_Identifier.
Ma non usi niente della estensione di RS_Identifier.

E' lecito questo impiego ?

A margine una domanda:

visto che mettiam dei codici prefissati derivanti dal profilo RNDT,
non sarebbe il caso , come fanno negli esempi che mi citavi, di inserire 
anche il tag codespace in cui indicare il codespace appunto da cui 
proviene la stringa che inseriamo nel campo a testo libero ?


Infatti se in tale campo a testolibero ci si inserisce una stringa del tipo
ROMA40/OVEST
che e' tra quelle previste e che per chi lavora in italia sa' che 
corrisponde a epsg:3003

come riporta il RNDT,

all'estero non sanno che vuol dire ROMA40/OVEST.
se inserissimo un codespace che punta alla codelist o comunque che 
identifichi il codespace da cui tali definizioni provengono almeno 
daremmo una traccia per localizzarli.


Non pensi ?

A.

Il 08/11/2014 18:37, Piergiorgio Cipriano ha scritto:

Ciao Sandro,
occhio a non confondere, sono due tag completamente diversi.

Quello chiesto da RNDT (e da Inspire ma per la sola parte 
interoperability, cioè non per il discovery) è previsto dallo schema 
19139 all'inizio del metadato xml, ptima della parte su 
identificationInfo:


/gmd:metadataStandardVersion
gmd:referenceSystemInfo
gmd:MD_ReferenceSystem
gmd:referenceSystemIdentifier
gmd:RS_Identifier
gmd:code
gco:CharacterStringetrs89/gco:CharacterString
/gmd:code
/gmd:RS_Identifier
/gmd:referenceSystemIdentifier
/gmd:MD_ReferenceSystem
/gmd:referenceSystemInfo


Quello che hai indicato tu sta verso il fondo, subito prima della 
parte su distributionInfo, e non è richiesta né da Inspire né RNDT:


gmd:extent
gmd:EX_Extent
gmd:verticalElement
gmd:EX_VerticalExtent
gmd:minimumValue
gco:Real15.56/gco:Real
/gmd:minimumValue
gmd:maximumValue
gco:Real345.15/gco:Real
/gmd:maximumValue
gmd:verticalCRS 
xlink:href=http://www.epsg-registry.org/export.htm?gml=urn:ogc:def:crs:EPSG::4979/

/gmd:EX_VerticalExtent
/gmd:verticalElement
/gmd:EX_Extent
/gmd:extent
/gmd:MD_DataIdentification
/gmd:identificationInfo
gmd:distributionInfo

Se nel metadato hai entrambi va benissimo, semplicemente sia Inspire 
che RNDT ignoreranno questo secondo elemento.
(vedi XML di prova qui: 
https://www.dropbox.com/sh/6tfhr7um13ua639/AABFd7utwNUvpkskuARu4nn3a?dl=0)




Andrea: visto che ti appassionano i disallineamenti tra RNDT, 
Inspire e ISO, ti segnalo che sul redmine usato dal MIG Inspire ci 
sono queste due:
- https://ies-svn.jrc.ec.europa.eu/issues/2238 ... proprio sui valori 
di CRS
- https://ies-svn.jrc.ec.europa.eu/issues/2212 ... sulla diversa 
interpretazione di useLimitation tra Inspire e ISO


pg






pg
__
Piergiorgio Cipriano
https://twitter.com/PgCipriano

Il giorno 08 novembre 2014 18:03, a.furi...@lqt.it 
mailto:a.furi...@lqt.it ha scritto:


On Sat, 8 Nov 2014 17:36:13 +0100, Piergiorgio Cipriano wrote:

No, state sbagliando.

Il tag  è previsto dallo standard ISO19115, e nella sua
rappresentazione XML è qualcosa del genere:

 ...

RNDT ha solo previsto che anziché valorizzare quel tag con una
semplice stringa () si faccia riferimento ad una lista di valori
predefiniti.

Niente di più, niente di meno di quanto è stato fatto a livello
INSPIRE, per metadati di dati conformi alle Data Specification dei
vari temi, dove (Data Specification) potete trovare la lista
di valori
EPSG, da valorizzare come URI.


Piergiorgio,
grazie per il chiarimento.

in effetti rileggendo meglio le note RNDT non dicono affatto che
quell'elemento
MD_ReferenceSystemCode e' un tag XML
si parla semplicemente di una lista di valori predefiniti in base
alle specifiche
del DM (ovviamente: fatte su misura per il contesto italiano).
a conferma, lo snippet XML presente nel doc RNDT e' questo qua:

gmd:extent
  gmd:EX_Extent
...
gmd:verticalElement
  gmd:EX_VerticalExtent
gmd:minimumValue
  gco:Real15.56/gco:Real
/gmd:minimumValue
gmd:maximumValue
  gco:Real345.15/gco:Real
/gmd:maximumValue
gmd:verticalCRS

xlink:href=http://www.epsg-registry.org/export.htm?gml=urn:ogc:def:crs:EPSG::4979/
  /gmd:EX_VerticalExtent
/gmd:verticalElement
  /gmd:EX_Extent
/gmd:extent

insomma, e' assolutamente chiaro che il ruolo di quel
MD_ReferenceSystemCode e'
semplicemente quello di fissare una volta per tutte quali sono i
valori

Re: [Gfoss] Metadati RNDT estensione della specifica e foglio excel per generare schede RNDT

Abbastanza chiaro.

Pero' questo presuppone comunque che ci sia un namepsace codificato per
poterlo inserire in quella url che deve rappresentare una codifica
esistente.

http://www.opengis.net/def/crs/EPSG/0/4936 -- epsg:4326

Io non credo di poter scrivere
http://www.opengis.net/def/crs/RNDT/0/ROMA40
http://www.opengis.net/def/crs/EPSG/0/4936

a meno che RNDT non sia un codespace codificato a livello internazionale.

Pero' se capisco la tua spiegazione,
siccome il problema nasce solo quando si condivide i dati a livello europeo.
Al momento della condivisione, il dato non sara' piu' roma40 perhe'
viene giocoforza convertito in un altro sistema di riferimento (ad
esempio: epsg:3003) e quindi a quel punto il problema di come esprimerlo
e' risolto perche' diventerebbe
http://www.opengis.net/def/crs/EPSG/0/3003
http://www.opengis.net/def/crs/EPSG/0/4936

il ragionamento non fa una grinza.

Spero di aver capito bene.

Il 08/11/2014 19:26, Piergiorgio Cipriano ha scritto:

Questo lo trovi in ciascun documento di data specification, per
esempio quello su Administrative Units a pag. 60:

http://inspire.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_AU_v3.1.pdf

Gli elementi aggiuntivi di cui parlavo sopra sono quelli elencati a
pag.95 del documento:

http://inspire.ec.europa.eu/documents/Metadata/MD_IR_and_ISO_20131029.pdf

[Gfoss] Traduzione in italiano di alcuni termini ISO da plugin Francese QSphere.

2014-11-07 Per discussione aperi2007


Salve,
sto collaborando con dei soggetti Francesi per tradurre un plugin 
(qsphere) dal francese all'italiano.


Nel tradurre i vocaboli della codelist dei ruoli, ho fatto caso ad 
alcuni dettagli interessanti che vorrei condividere co la lista gfoss.


I termini ISO con le relative traduzioni in francese sono i seguenti:

resourceProvider;Fournisseur de la ressource
custodian;Gestionnaire
owner;Propriétaire
user;Utilisateur
distributor;Distributeur
originator;Commanditaire
pointOfContact;Point de contact
principalInvestigator;Maître d'oeuvre
processor;Intégrateur
publisher;Éditeur
author;Auteur

Mi ha particolarmente colpito il senso della traduzione fancese di

principalInvestigator che ISO definisce cosi':
key party responsible for gathering information and conducting research

E' molto interessante il senso con cui lo hanno tradotto i francesi: 
Maître d'oeuvre

che sarebbe il nostro Direttore-dei-lavori.

E anche il termine originator che per ISO sarebbe:
party who created the resource

Usualmente io ero solito tradurlo nel concetto di autore (colui che crea 
materialmente).


Pero' ISO propone anche Author e quindi sarebbe stato un doppione.
I francesi lo hanno quindi tradotto in Commanditaire
che sarebbe il Committente o il Finanziatore.

A me questi due termini Direttore dei lavori e Committente 
convincono molto .


E per questo ho ritenuto che fosse utile condividere con la lista questa 
novita'.


Ovviamente si tratta della traduzione in italiano del pluginFrancese 
QSPhere.

Niente di piu'.
:)

Saluti,

Andrea Peri.

___
Gfoss@lists.gfoss.it
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+40 iscritti al 5.6.2014

Re: [Gfoss] Una questione legale su plugin come OpenLayers

2014-10-26 Per discussione aperi2007


Pero' parlano di software.

GoogleEarth e' quella buffa sfera che modellizza il globo terrestre.

Sinceramente leggendo il software son portato a pensare che non posso 
infilare tale sfera in un mio eventuale programma che la mostra come 
parte integrante di esso.


Ma non mi sentirei impedito a usare i dati.

Ovviamente si tratta di capire come pescare tali dati.

GE e' un programma applictivo e quindi in teroia potrebbe colloquiare 
con un protocollo criptato con i servers di BigG.
In tal caso non potrei usare i dati al di fuori di GE perche' non ne 
srei capace.
Ma se passassero in chiaro e le chiamate fossero con un protocollo che 
e' stato reso noto allora il discorso cambierebbe.


Quindi , a parer mio dai punti che te riporti parebbe che loro vogliono 
solo proteggere il software (la sfera ruzzolante).


A.


Il 26/10/2014 10:50, Geo DrinX ha scritto:

Riguardo GoogleEarth, questa è la licenza d'uso, in italiano:

http://earth.google.com/intl/it/license.html

I punti importanti sono:

l'utente non può utilizzare il Software in connessione con alcun 
prodotto, sistema o applicazione installata, connessa a o in 
comunicazione con veicoli


L'utente non può utilizzare il software in modo da consentire a lui 
stesso o a qualsiasi altra persona l'accesso a download o a feed di 
massa di coordinate numeriche di latitudine e longitudine. Non può 
inoltre utilizzare il Software per la stampa o il download di massa di 
immagini, dati o altri contenuti



Quindi, in sostanza :  non guidate con l'ausilio di Google Earth  e 
 non fate download di massa di immagini o coordinate.


Il limite da osservare sta nella parola di massa.


Per gli usi normali esiste il KML,  che non sarebbe stato divulgato 
se non fosse possibile fare nulla all'interno di Google Earth.





Roberto

Il giorno 25 ottobre 2014 20:38, G. Allegri gioha...@gmail.com 
mailto:gioha...@gmail.com ha scritto:


Penso anch'io, come Andrea, che l'interesse di Google sia rivolto
(come sempre) all'acquisizione di dati.
Le condizioni imposte dalle licenze gli servono per poter
ridefinire, quando e come vogliono, le proprie strategie
commerciali, più che per tutelare la proprietà intellettuale del
contenuto informativo di una mappa...

giovanni

Il 25/ott/2014 18:02 Andrea Peri aperi2...@gmail.com
mailto:aperi2...@gmail.com ha scritto:

E' sicuramente come dici te.
Solo in un punto non concordo.
BigG non opera come WU.
NOn la fa' usare per un tot di tempo per poi stringere il laccio.

Io penso piuttosto che la sua strategia sia rivolta ai BigData.
Per cui gli serve di conoscere tutto di chi naviga, compreso cosa
guarda sulla cartografia.

Io penso che per ogni zoom e pan che un utente fa su GM viene
registrato da qualche parte tale fatto.
Per incrociare dati e ottenere dati di dettaglio interessanti.

Come e' ovvio che BigG registri nei logs ogni ricerca che
viene fatta,
cosi' registra sicuramente ogni zoom o pan.
Magari registrando scala e centroide (gli basta) della mappa
inviata.

mio parere ...
:)

A.


Il 25 ottobre 2014 17:53, stefano campus skam...@gmail.com
mailto:skam...@gmail.com ha scritto:
 nella sessione di asita 2014 dedicata al nuovo sistema di
riferimento
 nazionale, una relazione ha fatto riferimento, in sintesi,
al fatto che
 google maps et similia hanno in qualche modo svilito il
sacro campo della
 cartografia, per esempio in relazione alle proiezioni,
all'accuratezza della
 georeferenziazione delle immagini ecc.
 ma un fatto resta: senza google map, bing non ci sarebbe
stato questa
 esplosione di voglia di cartografia.

 al che, mi sorge un dubbio: fatto salvo che le condizioni di
utilizzo in
 particolare di google maps sono quelle descritte da andrea
(vietata la
 derivazione, vietato l'utilizzo delle immagini a fini
commerciali tipo
 relazioni progettuali ecc), non è che invece google
incoraggi questi
 utilizzi esercitando in questo modo un controllo di fatto
del mercato?

 se ci pensate sembra proprio la politica di whatsapp: te lo
faccio scaricare
 gratis e lo usi per un tot di tempo, poi, quando sei
completamente dentro e
 tutti i tuoi amici lo usano, ti chiede 1 euro all'anno.

 insomma, a me sembra che se google davvero volesse evitare
un uso
 improprio non metterebbe a disposizione api e strumenti
per creare
 applicazioni utilissime come il plugin open layers.

 mio parere...

 s.



 --
 View this message in context:

Re: [Gfoss] Una questione legale su plugin come OpenLayers

2014-10-26 Per discussione aperi2007


Appunto per questo la vogliono proteggere.

Se invece di 400milioni di utenti, ne avesse avuti 400.000
avrebbero fatto una API e messo a punto un sdk per poterla integrare nei 
vari softwares.

Ne avrebbero cioe' incentivato l'utilizzo in ogni dove.

(Sempre con l'accortezza di registrarsi per ogni singolo zoom/pan il 
dato . Perche' il business e' primariamente nei dati.)


Invece la sfera ha 400milioni di utenti e quindi sta' bene li' dove e' , 
senza bisogno di fornire sdk , ma anzi vietandone l'uso in altri softwares.


:)

A.

Il 26/10/2014 11:06, Geo DrinX ha scritto:


La sfera ruzzolante, come tu la chiami, ha 400 milioni di utenti.   
Un gran numero di loro ne fa un buon uso anche in situazioni di emergenza.


Ruzzola molto bene.

:)



___
Gfoss@lists.gfoss.it
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+40 iscritti al 5.6.2014

Re: [Gfoss] QGIS - Segnalazione ai geologi

2014-10-13 Per discussione aperi2007


Queste accuse sono totalmente infondate, e mi dispiace molto che tu le 
riferisca qui.
Piu' trasparenza di discutere_tutto_  in liste pubbliche, cosa dobbiamo fare?



In effetti il termine e' troppo forte.
Avrei dovuto usare un termine piu' blando.
Anziche' maggiore trasparenza, avrei dovuto dire maggiore chiarezza.
Di questo ti chiedo scusa, perche' vedo che la vivi come un fatto personale.

Pero' , non vorrei che il mio ragionamento venisse travisato.

Io sono molto favorevole che in un prodotto come QGIS ci sia un gruppo 
che guida , e che prende le decisioni.
Basterebbe che poi queste decisioni vengono opportunamente divulgate e 
messe a conoscenza di tutti gli interessati.
Anziche' basarsi su una pseudo discussione dove in realt'a non vi è 
quasi mai niente da discutere.

Io traggo l'impressione che siano gia' cose decise a priori.

Anche perche' a volte capita che non ci sia una chiara maggioranza tra 
quelli che si esprimono, ma comunque si procede con quello che si era 
proposto fin dal principio.


Come se , ma e' solo una impressione, le cose siano gia' state discusse 
prioritariamente in un gruppo ristretto.


Te ne cito una per esempio:

un bel giorno instalando la dev di qgis, mi sono visto chiedere dal 
softare l'accettazione della licenza Oracle, se rifiutavo il programma 
non mi installava qgis.
Quindi da quel giorno in avanti semi volevo installare qgis dovevo 
accettare che il software mi installasse il driver oracle e io 
accettassi la sua licenza.

Altrimenti ciccia

Eppure non mi pare di aver mai visto passare in ML qgis una aperta e 
franca discussione circa tale fatto.


Per completezza preciso che:
e' vero che tale cosa viene eseguita da OSGEO4W , ma dentor QGIS vi e' 
un provider nativo che sfrutta tale driver e questo ignifica che a un 
certo momento qualcuno ha ritenuto opportuno o conveniente o preferibile 
(mettila come ti pare) che QGIS usi e richieda la presenza di tale driver.


Questa cosa e' stata sicuramente discussa, ma non certo in ML.

Niente da eccepire ripeto, perche' se ce un gruppo che decide ,allora 
decide anche di queste cose,,
ma che non mi venga poi a intortare raccondanto che tale desione e' 
stata condivisa e la decisione e' stata presa di comune accordo con la 
ML ...


:)

A.

Il 13/10/2014 13:34, Paolo Cavallini ha scritto:

Ma sinceramente un po più do trasparenza o glasnost nelle scelte e nei motivo di
certe scelte effettuate in qgis sarebbe auspicabile.
E il rispetto di chi lo sta usando.

Queste accuse sono totalmente infondate, e mi dispiace molto che tu le 
riferisca qui.
Piu' trasparenza di discutere_tutto_  in liste pubbliche, cosa dobbiamo fare?



___
Gfoss@lists.gfoss.it
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+40 iscritti al 5.6.2014

Re: [Gfoss] QGIS - Segnalazione ai geologi

2014-10-13 Per discussione aperi2007



Il 13/10/2014 18:05, Paolo Cavallini ha scritto:

Non qualcuno: lo sviluppo di QGIS e' completamente trasparente, ed e' molto 
facile
vedere chi ha fatto cosa. Nello specifico, il lavoro sul provider per Oracle e' 
stato
fatto da Juergen Fischer.


Non ce bsogno di fare nomi e cognomi.
Il mio era solo un esempio di una cosa che non era stata discussa nella 
ML di qgis.


Rpeto , per me ha fatto anche bene. Se dietro ce un gruppo di lavoro che 
coordinae decide.

Mi convince meno se le iniziative sono lasciate a chi puo' .



Questa cosa e' stata sicuramente discussa, ma non certo in ML.

Ripeto: non e' cosi'.



Capisco che lo ripeti, ma lo dimostri ?

Io non ne ho visto traccia in ML.
Ma comunque il concetto va oltre la questione di oracle.

Tra l'altro faccio notare che spesso un utente le novita' le nota solo 
quando viene rilasciata una versione nuova stabile.

Per cui , dopo diviene anche difficile fare retromarcie.

E qui si ritorna al discorso originale:

Se consideriamo un ottimo programmatore che ha i diritti di commit del 
repo di qgis.

Se questi gli gira di inserire una novita' prende la fa' e la inserisce.

Invece un altro ottimo programmatore che pero' non ha i diritti di 
commit , col cavolo che puo' committare cio' che ha fatto.
Il suo codice puo' essere accettato subito, oppre restare parcheggiato 
piu' o meno a lungo per varie questioni.


Ma il problema non è che il codice resti parcheggiato.
Infatti e' comprensibile che cio' avvenga, visto che la  maggior parte 
di chi lavora su base volontaria su qgis non deve per forza dedicare il 
suo tempo a lavorare per il commit del codice di altri.


Ma se uno trova tempo per lavorare in modo volontario a fare una nuova 
evoluzione (come un provider) , e poi se la committa seduta stante, 
disponendo dei diritti di commit del codice, e rimandando la discussione 
al dopo, ammetterai che da l'impressione di agire in un ruolo di 
padre-padrone del sistema.


Te dici che non e' cosi'.
Me lo auguro e spero che hai ragione te.

Ma continuo a restare della idea che era piu' corretto dire stanno e 
non stiamo.

:)

Aggiongo che il caso dei CAD-Tools è proprio un caso opposto, in cui la 
discussione e' stata fatta a priori, tante0 che ne ho letto traccia 
nella ML.

Ma , per restare in tema:
puo' darsi che sia stata discussa preventivamente, perche' chi la 
proponeva non aveva i diritti di commit , e quindi doveva prima

assicurarsi la benedizione dei committers ?
:))

A.

___
Gfoss@lists.gfoss.it
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+40 iscritti al 5.6.2014

Re: [Gfoss] QGIS, le Mappe e la Storia

2014-10-09 Per discussione aperi2007

E' una storia infinita.

AI tempi dell'universita' tra gli svaghi tipici vi era la ricostruzione
in scala delle famose battaglie.
Pur non avendo mai ricostruito waterloo , salvo al computer (che non fa
testo).

Parlando con esperti della materia, mi raccontavano che
le ricostruizioni divergono tra storici francesi e inglesi.

Per i primi fu' solo una fortunaccia dannata degli inglesi. E un leggero
tradimento.

Napoleone era riuscito a sfondare le linnee inglesi. e se fu sopraffatto
dai prussiani fu solo perche' il generale fancese che doveva tallonare i
Prussiani e assicurarsi che non ritornassero sul campo di battaglia
disattese gli ordini lasciandosi distanziare.
Quando le truppe francesi che inseguivano i prussini arrivarono a
waterloo ormai il fatto era compiuto.

A sostegno di questa tesi, portano il fatto ineccepibile che tale
generale , con la restaurazione venne nominato a un ruolo superiore dal
nuovo re di francia.

(e francamente questo e' un bell'indizio).

Altro elemento:

il giorno prima Napoleone vinse lo scontro con i prussiani a quatre-bra.
Poi (col senno di poi fu un errore, ma difficile decidere sul momento
una cosa del genere)
scelse di non attaccare subito gli inglesi che nel frattempo si erano
arroccati nella collina retrostante (waterloo) preferendo rimandare al
giorno dopo per riorganizzarsi.

Durante la notte piovve parecchio.
E il giorno dopo la cavalleria di Napoleone che era uno dei pezzi forti
del suo esercito si mosse con difficolta'. Sia perche' i generali erano
privi di esperienza, ma anche perche' il terreno era fangoso.

L'eroismo degli inglesi in tale battaglia e' indubitabile.
Ma certo Napoleone ebbe parecchie cose controdi se'.

Il colpo di grazie , fu' l'arrivo dei prussiani e la Leggerezza del
generale che doveva incalzarli.

Il 09/10/2014 17:36, Marco ha scritto:

...se avesse usato QGIS non sarebbe successo ;-)

http://spettacoliecultura.ilmessaggero.it/EVENTI/napoleone_sconfitto_errore_banale_waterloo_mappa_sbagliata/943237.shtml

--
View this message in context:
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/QGIS-le-Mappe-e-la-Storia-tp7589687.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian
mailing list mailing list archive at Nabble.com.
___
Gfoss@lists.gfoss.it
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+40 iscritti al 5.6.2014

Re: [Gfoss] QGIS, le Mappe e la Storia

2014-10-09 Per discussione aperi2007

In effetti vi e' un dettaglio che se avesse avuto un sistema di
rilevamento GIS moderno la storia avrebbe preos una altra piega.

GLi eserciti nell'era napoleonica non erano molto veloci.
Infatti una delle novita' che permise a Napoleone di sovrastare le
armate nemiche era la estrema rapidita con cui riusciva a muovere le sue
truppe non solo sui campi di battaglia, ma anche negli spostamenti a
medio e lungo raggio.

A Waterloo, a un certo punto, i prussiani in avvicinamento vengono
avvistati.
Ma Napoleone credette (o azzardo' come in altri casi) che si trattasse
del generale francese che stesse ritornando dopo aver disperso le truppe
Prussiane.
Che stesse ritornando per dargli manforte. Per cui prosegue nel suo
attacco coordinato verso la collina di Wellington.

Quando si accorge che in realta' si trattava dei Prussiani era ormai
troppo tardi, il suo attacco era gia' troppo avanti e non disponendo dei
giusti mezzi di comnicazione (sturmenti radio per la precisione) non fu'
in grado di trasmettere in tempo utile ai suoi comandanti l'ordine di
rivolgere le truppe verso i prussiani. Per far fronte a un attacco sul
fianco.

Tento' di ritardare i Prussiani lanciandogli contro la riserva
Imperiale, ma non riusci a trattenerli abbastanza e di conseguenza venne
sconfitto.

Probabilmente un GIS non gli sarebbe servito molto.
Napoleone era famoso per avere una visione perfetta del campo di battaglia.
Ma certo gli avrebbe fatto comodo una foto satellitare che mostrasse la
dislocazione dell'esercito suo, quello prussiano e l'esercito francese
dietro quello Prussiano.
Un buon satellite puntato sul campo di battaglia e oggi parleremmo tutti
francese.

Il 09/10/2014 18:08, aperi2007 ha scritto:

E' una storia infinita.

AI tempi dell'universita' tra gli svaghi tipici vi era la
ricostruzione in scala delle famose battaglie.
Pur non avendo mai ricostruito waterloo , salvo al computer (che non
fa testo).

Parlando con esperti della materia, mi raccontavano che
le ricostruizioni divergono tra storici francesi e inglesi.

Per i primi fu' solo una fortunaccia dannata degli inglesi. E un
leggero tradimento.

Napoleone era riuscito a sfondare le linnee inglesi. e se fu
sopraffatto dai prussiani fu solo perche' il generale fancese che
doveva tallonare i Prussiani e assicurarsi che non ritornassero sul
campo di battaglia disattese gli ordini lasciandosi distanziare.
Quando le truppe francesi che inseguivano i prussini arrivarono a
waterloo ormai il fatto era compiuto.

A sostegno di questa tesi, portano il fatto ineccepibile che tale
generale , con la restaurazione venne nominato a un ruolo superiore
dal nuovo re di francia.

(e francamente questo e' un bell'indizio).

Altro elemento:

Durante la notte piovve parecchio.
E il giorno dopo la cavalleria di Napoleone che era uno dei pezzi
forti del suo esercito si mosse con difficolta'. Sia perche' i
generali erano privi di esperienza, ma anche perche' il terreno era
fangoso.

L'eroismo degli inglesi in tale battaglia e' indubitabile.
Ma certo Napoleone ebbe parecchie cose controdi se'.

Il colpo di grazie , fu' l'arrivo dei prussiani e la Leggerezza del
generale che doveva incalzarli.

Il 09/10/2014 17:36, Marco ha scritto:

...se avesse usato QGIS non sarebbe successo ;-)

http://spettacoliecultura.ilmessaggero.it/EVENTI/napoleone_sconfitto_errore_banale_waterloo_mappa_sbagliata/943237.shtml

666+40 iscritti al 5.6.2014

[Gfoss] Un parere per capire se e' un bug di qgis

2014-09-24 Per discussione aperi2007


Ciao Giovanni,

devo rifare dei simboli SVG per il nostro progetto della Geologia.

Io devo fare dei simboli asimmetrici che devono collocarsi paralleli a 
dei dataset lineari.


Mi sono pero' trovato di fronte a un serio problema.

Che cerco di riassumete con un paio di immagini:
Per questo ho usato un simbolo SVG tra quelli dsponibili su qgis.

Nella prima immagine si vede il simbolo che si colloca correttamente 
sopra la linea .


Pero',
La vestizione prevede che il simbolo debba seguire con il suo profilo la 
linea,
se la liea è orizzontale, il simbolo parallelo alla linea deve essere 
orizzontale.

Se la linea piega, il simbolo deve parallelamente piegare pure lui.
Per ottenere questo, occorre spillare la checkbox
indicatore di rotazione.

Con tale opzione attivata il simbolo segue correttamente il profilo 
della linea.

Pero' si RIBALTA !

Nella seconda immagine mostro l'effetto massicio che si ottiene.

A questo punto il mio dubbio è che per ottenere il simbolo nel verso 
giusto, devo sostanzialmente costruire un simbolo SVG ROVESCIATO.


Un simbolo rovesciato per riaverlo diritto su QGIS:

Francamente ho molte perplessita', il rischio e' che poi se un geologo 
vede tale simbolo SVG ci prende per ubriachi.


Chi glielo va a spiegare che se lo usa su QGIS gli si raddrizza ?
:)

E se lo volesse usare su un altro GIS se lo tiene rovesciato ?

Sono alla ricerca di un workaround per risolvere questo problema senza 
dover ricorrere a un simbolo rovesciato.


Qualcuno ha gia' avuto a che fare con questo tipo di problematica ?

Grazie.

Andrea.

___
Gfoss@lists.gfoss.it
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+40 iscritti al 5.6.2014

Re: [Gfoss] Spatialite e limite di parametri in una singola query

2014-09-13 Per discussione aperi2007



Aggirerò il problema così:
memorizzo in un dizionario le coppie campi/valori che creano l'istanza 
di database in un dato momento. Così non dovrò cercare gli ID tramite un IN.


Non ho chiaro quello che devi fare, ma indubbiamente vi e' un limite 
nella lunghezza della espressione.


Pero' se cosi' e' , e se come ho capito te memorizzi gli ID in una 
tabella (il tuo dizionario),

li puoi invocare cosi':

where
campo1 IN (select valore from dizionario)
;

Se il problema e' la lunghezza della stringa SQL che non puo superare 
una certa lunghezza,

questa ultima sintassi dovrebbe funzionare.

E forse potresti anche usare

where
   campo1 EXISTS (select valore from dizionario)

A.

Il 13/09/2014 19:26, Luca Mandolesi ha scritto:



Il giorno 13 settembre 2014 13:45, Andrea Peri aperi2...@gmail.com 
mailto:aperi2...@gmail.com ha scritto:


Io non userei una serie smisurata di AND,
anche perche' metti a dura prova l'ottimizzatore della query.

Proverei a usare invece il costrutto IN

where
 campo1 IN ('valore1','valore2','valore3',.)


No, non funzia, lo vede sempre come un eccesso di patametri


Anche su postgres.


Postgres digerisce anche i sassi. Non ha problemi


prova e facci sapere se questo ammette piu valori di 999



Aggirerò il problema così:
memorizzo in un dizionario le coppie campi/valori che creano l'istanza 
di database in un dato momento. Così non dovrò cercare gli ID tramite 
un IN.


Nel caso avessi un'istanza di database che corrisponde a tutti i 
record faro solo una query id  0.


Per eliminare per esempio più di 1000 record non farò altri che 
segmentare i delete in pacchetti da 500.






--
-
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-




___
Gfoss@lists.gfoss.it
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+40 iscritti al 5.6.2014

Re: [Gfoss] Rilascio MapStore 1.5.1 con versione Mobile per Android

2014-03-23 Per discussione aperi2007


Ciao Simone.

Interessante questo tuo dettaglio per cui te lasci l'italia per questo 
mio intervento.
Ove, oltre tutto un aspetto non secondario era l'apprezzamento per il 
tuo prodotto.


Per il resto mi pare che il tuo intervento sia esso stesso la migliore 
risposta che io potrei darti.

Visto l'attegiamento che hai anche nei confronti dei tuoi collaboratori.

Ionon ci vedo niente di male nel recriminare visto che veod un prodotto 
valido fare uso di spatialite su una piattaforma di per se' abbastanza 
ostica (dalvik) e non avere niente di analogo su una piattaforma che non 
è piu' complessa (java)


Andando sul lato tecnico, innanzitutto, il supporto a spatialite di 
cui si parla si limita alla versione Android che non ha
niente a che fare con il java standard come sicuramente saprai in 
quanto il codice non è (quasi) mai portabile tra una

JVM standard e Dalvik.

Quindi se capisco la tua spiega, secondo te è stato piu' facile portare 
spatialite su dalvik piuttosto che su una piattaforma

Java Standard.

il porting di spatialite su Dalvik lo avete finanziato voi di 
Geosolutions di vostra iniziativa ?



Visto che ci hai citato spiego l'antefatto. Spatialite si puo' usare
abb tranquillamente in applicativi desktop basati su Java, ma su
applicativi lato server come GeoServer, perlomeno al  momento in cui
abbiamo fatto il famoso studio di ben 9 ore (o giu' di li non ricordo
nel dubbio posso anche condividerei timesheet giornalieri e le
relative fatture) aveva grossi (enormi?) problemi di gestione di
thread multipli e di scalabilità (questo a livello dei driver JDBC).



Non ho dubbi che su geoserver non sia facile da usare, ma strnaamente a 
me non risulta che mai ci si sia sognati di commissionare ad alcuna 
persona di supportare spatialite su geoserver.


Se proprio devo dirla tutta, a me risulta che ci fossimo interessati per 
la realizzazione di un driver spatialite per Geotools.


Evidentemente certe persone immaginano geotools e geoserver come due 
faccie della stessa medaglia e non si puo' agire sull'uno senza agire 
contestualmente anche sull'altro.

Questo pero' aumenta i costi a carico di chi finanzierebbe non credi ?

Comunque non sapevo di questo dualismo obbligato geotools-geoserver, lo 
scopro ora.




Senza voler criticare Furieri, mi ricordo una sua email girata anche
in questa lista dove evidenziava (su suggerimento di Even Roualt btw)
che spatialite inizializzava male GEOS (in modo non thread-safe) e
questo poteva portare a dei crash, cosa non accettabile in una
applicazione Java e che sicuramente era una delle sorgenti dei crash
che vedevamo.



A suo  tempo , quando mi giunse questa tua notizia, mi informai e emerse 
che la geos non è thread-safe

(lo sapevi ?)
Alcune parti in realta' lo sono , ma solo la parte dei messaggi, il 
resto non lo è.

Per cui la parte rilevante, quella della elaborazione non lo è.
Io non sono un programmatore di geos, ma se chi lo è mi dice che non è 
thread-safe io gli credo.

Queste notizie a te erano state fatte pervenire.

Con la ovvia conclusione che se la geos non e' thread-safe non ha senso 
parlare di inizializzarla in modalit'a thread-safe.
e comunque spatialite per questo ha implementato dei meccanismi di lock 
che se non sono thread-safe almeno impediscono le collisioni.


Credevo che queste cose le avessi contemplate.
Invece capisco da questo tuo intervento che ti eri fermato ben prima.

Termino qui perche' vedo che fai un gran mescolone di tante cose.

In ogni caso io facevo un apprezzamento del tuo prodotto recriminando 
sulla mancata occasione su spatialite con le geotools. E non potendo non 
notare che pero' nel tuo prodotto alla fine spatialite ci è entrato.

bello o brutto che fosse.
Non credo che ci fosse niente di cosi' male in tale intervento.

Forse cercavi solo la scusa buona e io non sapendolo te la ho fornita ?

almeno dimmi grazie.
:)

A.

On 23/03/2014 18:27, Simone Giannecchini wrote:

Salve Andrea,
trovi le mie risposte inline sotto.


Interessante questo mapstore 1.5.1

Veod che gestisce pure un db spatialite.

Come RT abbiamo finanziato anche uno studio per vedere se si riusciva a far
funzionare spatialite con l'ambiente java.
Ma la ditta a cui per vie traverse era stato dato l'incarico, una ditta
esperta su geotools, non ci risulta che alla fine avesse concluso alcunche'
di significativo.


Onestamente, essendo GeoSolutions un' azienda con sede legale e
operativa in Toscana che da lavoro a 15 persone di cui almeno 10
residenti in Toscana facendo il 70% del fatturato all'estero e pagando
circa 14k di IRAP l'anno, ci dispiace (a me e al management di
GeoSolutions) dover constatare questo ormai ovvio risentimento nei
confronti di GeoSolutions da parte della nostra regione con cui
peraltro non abbiamo MAI lavorato direttamente.

In qualità di rappresentante di GeoSolutions mi sento in dovere di
rispondere ancora una volta puntualizzando alcuni aspetti non solo dal
punto di vista tecnico e se questo comporterà di non lavorare

Re: [Gfoss] Info sull'utilizzo dei servizi OWS del GeoPortale Nazionale ....

2014-03-21 Per discussione aperi2007

Ma il PCN cosa offre di interessante ?

Proprio qualche gorno fa' , in un altro contesto interregionale, ho
sentito persone dire

che su internet ormai la pubblicazione dei dati cartografici è roba inutile.
Che tanto tra google , bing e un altro che non ricordo...
ce ne di avanzo.

Il ragionamento era rivolto a motivare che fare cartografia di tipo
aerofotogrammetrico è tempo perso e inutile.

Naturalmente non condivido,
ma a parte questo fatto.

Il punto interessante è che anche nei settori che dovrebbero fare
cartografia si va affermando il concetto che tanto basta Google con le
sue foto.

Forse l'obiettivo è cominciare a vedere dove si puo' risparmiare ?

E se il PCN banna i suoi utenti, forse si sta' tafazzando con le sue mani.
:)

Andrea.

On 21/03/2014 17:35, Novarese wrote:

Il PCN banna automaticamente gli indirizzi IP che accedono piu' di 70 volte
in 10 minuti consecutivi.

Ritengo che cio' accada per evitare (giustamente) attacchi di tipo DoS...

--
View this message in context:
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Info-sull-utilizzo-dei-servizi-OWS-del-GeoPortale-Nazionale-tp7587403p7587406.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian
mailing list mailing list archive at Nabble.com.
___
Gfoss@lists.gfoss.it
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

Re: [Gfoss] Info sull'utilizzo dei servizi OWS del GeoPortale Nazionale ....

2014-03-21 Per discussione aperi2007


sono completamente daccordo.

E' troppo bassa la soglia di 70 richieste in 10 minuti.
Tra lkaltro qgis consente di stamare una carta A0 da wms.
un utente che volesse stamparsi una carta A0 a 300dpi usando il wms del 
pcn come sfondo,

altro che 70 richieste in 10 minuti.

A.


On 21/03/2014 18:47, Andrea Aime wrote:
2014-03-21 17:35 GMT+01:00 Novarese emigr...@wp.pl 
mailto:emigr...@wp.pl:


Il PCN banna automaticamente gli indirizzi IP che accedono piu' di
70 volte
in 10 minuti consecutivi.

Ritengo che cio' accada per evitare (giustamente) attacchi di tipo
DoS...


Oddio, potrei capire 70 volte in un secondo, ma 70 in 10 minuti mi 
pare eccessivo,
facendo un po' di browsing su una mappa WMS, come si fa a non fare 
meno di 70 richieste
in 10 minuti? Se il client in questione è tiled, le farà in 30-60 
secondi...


Inoltre, limitazione per indirizzo IP? E se dietro il router unico di 
una grande azienda o pubblica
amministrazione ci sono 10 utenti che vorrebbero usare il PCN? Ti 
bannano in un soffio :-)


Ciao
Andrea

--
==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

---


___
Gfoss@lists.gfoss.it
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


___
Gfoss@lists.gfoss.it
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

Re: [Gfoss] Splitting polygons

2014-03-15 Per discussione aperi2007

Vi è anche il problema che nell'aritmetica dei computers non si riesce a
esprimere un numero reale qualsiasi.

Mettendo da parte il come fare a trovarla.
Vi è comunque il problema che la regola richiesta:

La somma delle aree dei poligoni contenuti (tutti con area uguale) deve
essere pari all'area del poligono risultante.

Non sempre è possibile nell'aritmetica dei computers.

Pensa a un poligono che abbia area 0.1.
Ovvero un numero non esprimibile in aritmetica binaria.

A parer mio non è possibile trovare un numero finito di poligoni aventi
area esprimibile in aritmetica binaria e la cui somma dia l'area di
partenza (che in binario non è esprimibile)

Per cui la risposta è che come regola generale : con i computers non è
possibile ottenere cio' che chiede Paolo.
Poi in casi particolari , ovvero quando l'area di un poligono assume
valori particolari puo' anche essere possibile trovare questi N
sotto-poligoni.

On 15/03/2014 00:20, giulianc51 wrote:

Il giorno Fri, 14 Mar 2014 02:19:02 -0700 (PDT)
emigrato adminfo...@wbg.lodzkie.pl ha scritto:

ciao Novarese (o ti devo chiamare Creativo visto le molteplici tue
identità? :-)

Di un problema analogo parlammo anche qui
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/split-poligono-tp7584909.html
, e finora non c'è soluzione...

no, non mi sembra lo stesso problema;

quello di Marco (tuo link) non è che non ha soluzioni, non ha
soluzione univoca, come nota Paolo nel suo commento;

il problema di Paolo su questa lista invece sì, sempre ovviamente che
io abbia capito bene :-)

ciao,
giuliano

Re: [Gfoss] Sperimentazione pip plugin per qgis per installare nuovi moduli python


On 06/03/2014 09:47, Luca Mandolesi wrote:
- invocare la shell giusta, tra Osgeo4w e Osgeo4w shell: anzi se c'è 
qualcuno che me la sa spiegare ben venga;


A me non sembra che ci sia differenza tra le due.
Chiamano i medesimi programmi e la finestra ha i medesimi settaggi.

A parer mio si tratta di una di quelle scorie che restano in osgeo4w e 
che nessuno rimuove perche' nessuno sa bene perche' è comparsa e teme di 
rompere qualche compatiblita'.


Andrea.

___
Gfoss@lists.gfoss.it
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

Re: [Gfoss] dimensioni di stampa dei font


Che font stai usando ?

Usando un font true-type o un openfont mi attenderei che la sua 
risoluzione vari in relazione al dispositivo su cui viene usato.


Diverso discorso se stai usando per le scritte dei rasters.

Se non è cosi' allora per me è un bug.

Peor' potrebbe trattarsi anche un altro fenomeno:
per cui qualche informazione extra potrebbe fornire l'imbeccata per 
arrivare a capire il problema:


La prima cosa che mi viene in mente è capire come la tua mappa arriva 
alla stampante:


Cioe': Attivi l'opzione stampa come raster   la lasci disattivata ?

tieni presente che se vai come raster, la risoluzione in DPI del raster 
che produci deve coincidere con quella che adotti per la stampa sulla 
stampante, altrimenti l'immagine si riduce e di conseguenza anche il font.


A.

On 06/03/2014 12:26, Geol. Matteo Gabrielli wrote:

Salve a tutti/e
ho da poco istallato qgis versione 2.3.0 master passando dalla 
precedente 1.9 che avevo su. Pur trovando notevoli migliorie, anche 
per quanto riguarda il compositore di mappe, trovo una non 
corrispondenza tra le dimensioni dei font mentre creo la mappa 
rispetto al file pdf o file immagine che salvo.
Devo usare un valore dei font molto alto per avere un risultato 
visibile nel risultato del file di stampa.

Suggerimenti ??




Dott. Matteo Gabrielli
Geologo
_n° 450 
O.G.R.U.

fraz. Croce di Castiglione, 9 Città di Castello
06012 Perugia - Italia
cell. 328.1970952

La vita è stato selvaggio. Quello che è più vivo è più 
selvaggio...Henry D. Thoreau


Privacy: D.Lgs. N.196/03


___
Gfoss@lists.gfoss.it
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


___
Gfoss@lists.gfoss.it
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

Re: [Gfoss] dimensioni di stampa dei font

Noi puntiamo a usare nelle nostre cartografie il Font Tuffy, che è 
anche gratuito.


E' un regular, ma nasce stretto come un Narrow.
http://www.fontsquirrel.com/fonts/Tuffy

A.

On 06/03/2014 12:33, Geol. Matteo Gabrielli wrote:
Grazie Paolo, non so cosa sia un ticket però proverò a fare prove con 
font diversi.






Dott. Matteo Gabrielli
Geologo
_n° 450 
O.G.R.U.

fraz. Croce di Castiglione, 9 Città di Castello
06012 Perugia - Italia
cell. 328.1970952

La vita è stato selvaggio. Quello che è più vivo è più 
selvaggio...Henry D. Thoreau


Privacy: D.Lgs. N.196/03


Il Giovedì 6 Marzo 2014 12:31, Paolo Cavallini cavall...@faunalia.it 
ha scritto:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 06/03/2014 12:26, Geol. Matteo Gabrielli ha scritto:

 Devo usare un valore dei font molto alto per avere un risultato 
visibile nel

 risultato del file di stampa.
 Suggerimenti ??

Prova con fonts diversi, poi apri un ticket.
E' abbastanza normale che nella versione di sviluppo, all'inizio di un 
ciclo di
rilascio, ci sia qualcosa di rotto, con la tua segnalazione sara' piu' 
facile sistemarlo.

Grazie.

- -- 
Paolo Cavallini - www.faunalia.eu

Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlMYXJkACgkQ/NedwLUzIr5TKgCeNrIK5nZy7iOTXgC9ZzjdSv0n
uloAoLFsW/cYs/zPI+NXRfG+Pzuv4s5H
=PmtR
-END PGP SIGNATURE-

___
Gfoss@lists.gfoss.it mailto:Gfoss@lists.gfoss.it
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




___
Gfoss@lists.gfoss.it
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


___
Gfoss@lists.gfoss.it
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

Re: [Gfoss] Taglio poligoni