Qgis - malfunzionamento vettorializzatore del plugin grass

[Andrea Fredduzzi]

Buongiorno a tutti.

Utilizzo abitualmente il vettorializzatore del plugin grass. Trovo molto comodo poter utilizzare il vettorializzatore topologico di grass, all'interno di qgis che mi consente di accedere e spegnere vari layer di sfondo (anche vettoriali) senza doverli importare in grass.

Dalla versione 2.4 di Qgis il vettorializzatore è inutilizzabile: tutto bene finché si spostano nodi e vertici o si inserisce una geometria. Quando invece si cancella un elemento qgis va in crash e, peggio, il vettore di grass risulta danneggiato e non si sistema ricostruendone la topologia.

Nella 2.6 il problema permane.

Vorrei sapere se qualcuno ha riscontrato lo stesso problema, se è un bug noto ecc.

Grazie

--

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666+40 iscritti al 5.6.2014

[pcav]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Caro Andrea,

Il 22/12/2014 11:24, Andrea Fredduzzi ha scritto:

> Utilizzo abitualmente il vettorializzatore del plugin grass. Trovo
> molto comodo poter utilizzare il vettorializzatore topologico di
> grass, all'interno di qgis che mi consente di accedere e spegnere
> vari layer di sfondo (anche vettoriali) senza doverli importare in
> grass. Dalla versione 2.4 di Qgis il vettorializzatore è
> inutilizzabile: tutto bene finché si spostano nodi e vertici o si
> inserisce una geometria. Quando invece si cancella un elemento qgis
> va in crash e, peggio, il vettore di grass risulta danneggiato e
> non si sistema ricostruendone la topologia. Nella 2.6 il problema
> permane. Vorrei sapere se qualcuno ha riscontrato lo stesso
> problema, se è un bug noto ecc.

purtroppo il plugin e' sostanzialmente non mantenuto da alcuni anni;
Faunalia ci ha investito, senza supporto da nessun ente o
utilizzatore, ma ora non siamo nelle condizioni di proseguire questo
sforzo.
concordo, ovviamente: e' un gran peccato.
d'altronde, anche questo e' l'ecosistema open source: la
responsabilita' e' condivisa, e i pezzi su cui non ci sono
investimenti pian piano declinano.
saluti.
- --
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlSZt48ACgkQ/NedwLUzIr7miwCgnH1rUxTMn61sYgNSDTxWjrGu
ofwAnjRglVhAmgaVt6TxOPbc1YuSrNPY
=hwn0
-----END PGP SIGNATURE-----
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666+40 iscritti al 5.6.2014

[Luca Delucchi]

2014-12-23 19:42 GMT+01:00 Paolo Cavallini <[hidden email]>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Caro Andrea,
>
> Il 22/12/2014 11:24, Andrea Fredduzzi ha scritto:
>> Utilizzo abitualmente il vettorializzatore del plugin grass. Trovo
>> molto comodo poter utilizzare il vettorializzatore topologico di
>> grass, all'interno di qgis che mi consente di accedere e spegnere
>> vari layer di sfondo (anche vettoriali) senza doverli importare in
>> grass. Dalla versione 2.4 di Qgis il vettorializzatore è
>> inutilizzabile: tutto bene finché si spostano nodi e vertici o si
>> inserisce una geometria. Quando invece si cancella un elemento qgis
>> va in crash e, peggio, il vettore di grass risulta danneggiato e
>> non si sistema ricostruendone la topologia. Nella 2.6 il problema
>> permane. Vorrei sapere se qualcuno ha riscontrato lo stesso
>> problema, se è un bug noto ecc.
>
> purtroppo il plugin e' sostanzialmente non mantenuto da alcuni anni;
> Faunalia ci ha investito, senza supporto da nessun ente o
> utilizzatore, ma ora non siamo nelle condizioni di proseguire questo
> sforzo.
> concordo, ovviamente: e' un gran peccato.
> d'altronde, anche questo e' l'ecosistema open source: la
> responsabilita' e' condivisa, e i pezzi su cui non ci sono
> investimenti pian piano declinano.

se è un gran peccato, come da te detto, le funzionalità dovrebbero
essere mantenuta anche senza investimenti.
Mi spiace vedere come sempre più progetti se non c'è un investimento
non mantengono feature già esistenti (che dal mio punto di vista è
molto grave) o non ne implementino di nuove.

> saluti.
>

--
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666+40 iscritti al 5.6.2014

[Silvio Grosso]

Salve a tutti,

Luca Delucchi ha scritto:
> Mi spiace vedere come sempre più progetti se non c'è un investimento
> non mantengono feature già esistenti (che dal mio punto di vista è
> molto grave) o non ne implementino di nuove.

Luca, capisco il tuo disappunto e concordo che e' un peccato che Grass non sia sempre "integrato" al meglio in Qgis.
Leggendo la mailing list inglese degli sviluppatori di Qgis mi e' parso di capire che la versione 7 di Grass potrebbe essere ancora piu' difficile da gestire in Qgis.
Qualcuno ha notizie recenti a riguardo ?
C'e' qualche sviluppatore di Qgis che sta lavorando per integrare Grass 7 in Qgis ?

Secondo me e' assolutamente "naturale" che alcune parti di Qgis siano abbandonate in mancanza di opportuni finanziamenti economici.
Nel caso specifico di questa opzione (vettorizzazione del plugin Grass) non penso neanche che sia cosi' grave perche', secondo me, sarebbe meglio spingere gli utenti ad usare direttamente l'interfaccia grafica di Grass :-)
Siccome so che questa mia ultimissima "considerazione" potrebbe provocare parecchie critiche (molte condivisibili) cerco di argomentare meglio cosa intendo.

Come appassionato di fotoritocco uso da anni G'MIC.
G'mic comprende una raccolta di centinaia di filtri, oltre 600, da applicare sulle proprie immagini [1]: funziona nativamente su Linux da linea di comando su immagini jpeg, tiff ecc (8 bit, 16 bit, 32 bit ecc).
Attualmente e' possibile utilizzare G'mic anche con l'interfaccia grafica di Gimp (http://www.gimp.org/) tramite un plugin.
Il problema della versione stabile attuale di Gimp 2.8.x e' che gestisce bene solo le immagini, in particolare jpeg, con 8 bit per canale di colore.
La prossima versione stabile di Gimp, la 2.10, gestira' invece anche i file con 16 bit - 32 bit ecc per canale di colore (Tiff - Raw ecc).
Purtroppo Gimp 2.10 potrebbe richiedere ancora diversi anni per essere rilasciato.
Inoltre, per poter sfruttare questa nuova opzione, anche G'mic dovrebbe essere adattato e questo comporta una enorme mole di lavoro.
Sia gli sviluppatori di Gimp che quello unico di G'mic lavorano gratuitamente e questo giustifica i tempi lunghi e non prevedibili.

Recentemente G'mic e' stato incluso in Krita [2].
A me, all'inizio, e' parsa subita una evoluzione enorme rispetto a Gimp perche' Krita gestisce da sempre i file Tiff e Raw (16 bit e 32 bit).
Purtroppo il mio entusiasmo iniziale e' man mano scemato perche' anche Krita non sfrutta al meglio G'mic.
Molti filtri avanzati non funzionano e G'mic e' molto meglio integrato e stabile in Gimp (jpeg) rispetto a Krita (jpeg + tiff, raw ecc)...
Gli sviluppatori open source di Krita hanno sempre incentivato le sponsorizzazioni economiche degli utenti finali ma, attualmente, esse bastano a malapena per 1 sviluppatore a tempo pieno [3].
G'mic e' quindi poco sviluppato e stabile in Krita anche perche' non ci sono risorse economiche sufficienti per questo lavoro.
Krita ha oltre 300.000 linee di codice in C++ (senza considerare nel conto le librerie Qt e di Kde) e servirebbero altri sviluppatori a tempo pieno per stabilizzare e migliorare G'mic e tutte le altre funzionalita' [4]

Lo sviluppo software di G'mic con Gimp - Krita, secondo me, ricalca un po' i problemi di Qgis - Grass...
Ecco perche' ritengo che gli utenti GIS dovrebbero essere sempre "incentivati" a specializzarsi sopratutto nei vari software GIS (SpatiaLite, PostGIS ecc...): il che ovviamente e' molto piu' dispendioso come tempo...
Nei software commerciali si nota spesso la stessa tendenza ad accentrare in una unica applicazione diverse funzionalita' molto disparate tra loro.
Attualmente, per esempio, sia Microsoft Office (con Power Point) che Photoshop permettono di effettuare delle piccole modifiche sui video...
In genere questo raggruppamento di opzioni avviene anche perche' "l'utente medio" preferisce spesso avere tutte le funzionalita' in un unico software (cosi' non si deve sforzare di apprendere troppi software...).

Scusatemi per il lungo messaggio che NON ha nessuna intenzione di suscitare un coro di proteste.
Presumo infatti che siano veramente *pochissimi* gli utenti di questa lista favorevoli a separare Grass da Qgis in futuro (e ne immagino le varie ragioni...) :-)
Senza finanziamenti economici specifici temo pero' che difficilmente ci possano essere grandi miglioramenti futuri (vedi messaggio iniziale)...

Cordiali saluti

Silvio Grosso

[1] http://gmic.eu/
[2] https://krita.org/item/krita-2-9-first-beta-released/
[3] http://libregraphicsworld.org/blog/entry/boudewijn-rempt-on-the-state-of-affairs-with-krita-foundation
[4] http://www.valdyas.org/fading/index.cgi/kde/krita_10_years.html

[stefano campus]

ti ringrazio per l'excursus.
non conoscevo neanche lontanamente l'esistenza di gmic

grazie mille

s.

[pcav]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Il 29/12/2014 20:28, Silvio Grosso ha scritto:

> Luca, capisco il tuo disappunto e concordo che e' un peccato che
> Grass non sia sempre "integrato" al meglio in Qgis. Leggendo la
> mailing list inglese degli sviluppatori di Qgis mi e' parso di
> capire che la versione 7 di Grass potrebbe essere ancora piu'
> difficile da gestire in Qgis. Qualcuno ha notizie recenti a
> riguardo ? C'e' qualche sviluppatore di Qgis che sta lavorando per
> integrare Grass 7 in Qgis ?

C'e' da fare manutenzione per adattare il plugin ai cambiamenti
rilevanti di GRASS 7. Ci sta lavorando a scappatempo qualcuno, ma e'
possibile che questo non basti.

> Secondo me e' assolutamente "naturale" che alcune parti di Qgis
> siano abbandonate in mancanza di opportuni finanziamenti
> economici.

Confermo: i finanziamenti sono necessari per fare manutenzione e nuovo
sviluppo; con il solo volontariato si possono fare solo aggiustamenti
minori, a meno che non si sia sostenuti da enti.
Non solo: in un certo senso e' anche "giusto" abbandonare quello che
non interessa a sufficienza per essere sostenuto.

> Nel caso specifico di questa opzione (vettorizzazione del plugin
> Grass) non penso neanche che sia cosi' grave perche', secondo me,
> sarebbe meglio spingere gli utenti ad usare direttamente
> l'interfaccia grafica di Grass :-)

Credo che la maggior parte degli utenti amino usare meno interfacce
possibili, e fare tutto entro una sola applicazione. Se potessero, gli
utenti moderni userebbero solo un browser per fare qualunque cosa :)

Saluti.

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

iEYEARECAAYFAlSm7+QACgkQ/NedwLUzIr64JACeMxvXyBUGISXl8lLWChOkz+oQ
uHYAn2VH5jIbHRKoUjVWxYOV7hi2QKpk
=sbTN
-----END PGP SIGNATURE-----
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666+40 iscritti al 5.6.2014

[amefad]

Il giorno 02/gen/2015 20:22, "Paolo Cavallini" <[hidden email]> ha scritto:
> Se potessero, gli
> utenti moderni userebbero solo un browser per fare qualunque cosa :)
>
E ciò è MALE almeno quanto incrociare i flussi... (IMHO )
Oggidì un browser qualunque si mangia 300mb di RAM all'apertura...

Concordo con Silvio che nel nostro mondo vale la pena usare 2-3 interfacce, ma spero che si possa finanziare il plugin che per molti come me è stata la porta d'ingresso a GRASS.

Amefad

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666+40 iscritti al 5.6.2014

[Marco]

pcav wrote

...i finanziamenti sono necessari per fare manutenzione e nuovo
sviluppo; con il solo volontariato si possono fare solo aggiustamenti
minori, a meno che non si sia sostenuti da enti.
Non solo: in un certo senso e' anche "giusto" abbandonare quello che
non interessa a sufficienza per essere sostenuto.

Se qualcuno apre una sottoscrizione (come quella di poco tempo fa per la traduzione del manuale) io le mie 5 - 10 euro sono pronto a mettercele ...se Parigi val bene una messa, figuriamoci se, implementare QGIS affinché continui a "parlare" con GRASS, non valga una pizza margherita ;-) ...se poi questa sottoscrizione fosse internazionale, visto quanto è ampia la comunità mondiale GFOSS in genere e/o QGIS nello specifico, credo che, con qualche dollaro a testa, nel giro di qualche settimana si trovino i fondi necessari per finanziare questo progetto.

pcav wrote

Credo che la maggior parte degli utenti amino usare meno interfacce
possibili, e fare tutto entro una sola applicazione. Se potessero, gli
utenti moderni userebbero solo un browser per fare qualunque cosa :)

Io sono decisamente e convintamente tra questi
(inoltre, se non sbaglio, mi è sembrato di capire che GRASS 7, molto molto presto, opterà come standard sul formato SPLITE relegando il formato SHAPE a subordinato mentre QGIS, ancora per molto tempo, manterrà, come standard, il formato SHAPE. Questo potrebbe significare che, volendo usare QGIS e GRASS come programmi distinti ma con gli stessi dati, oltre a dover "imparare" ad usare due GUI diverse per fare le stesse cose, (fastidioso ma accettabile), bisognerà anche saper gestire (e temo archiviare) gli stessi dati ora in SPLITE ora in SHAPE.

[Luca Lanteri-3]

[...]

Io sono decisamente e convintamente tra questi
(inoltre, se non sbaglio, mi è sembrato di capire che GRASS 7, molto molto
presto, opterà come standard sul formato SPLITE relegando il formato SHAPE a
subordinato mentre QGIS, ancora per molto tempo, manterrà, come standard, il
formato SHAPE. Questo potrebbe significare che, volendo usare QGIS e GRASS
come programmi distinti ma con gli stessi dati, oltre a dover "imparare" ad
usare due GUI diverse per fare le stesse cose, (fastidioso ma accettabile),
bisognerà anche saper gestire (e temo archiviare) gli stessi dati ora in
SPLITE ora in SHAPE.

Non vorrei sbagliarmi ma per come è strutturato GRASS penso che nel futuro continuerà ad utilizzare il suo formato interno. Già adesso tra l'altro non utilizza direttamente gli shapefile ma li importa.  Cosa diversa per la parte alfanumerica che dalle ultime versioni viene gestita con sqlite e non più dbf. Correggetemi se dico castronerie.

Anche QGIS non ha come formato standard lo shapefile ma tutti i formati gestiti da GDAL/OGR ed ha anche un ottimo supporto per PostGIS e SPLITE.

Luca

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666+40 iscritti al 5.6.2014

[pcav]

Esatto.
Saluti.

Il 03 gennaio 2015 18:17:14 CET, Luca Lanteri <[hidden email]> ha scritto:

[...]

Io sono decisamente e convintamente tra questi
(inoltre, se non sbaglio, mi è sembrato di capire che GRASS 7, molto molto
presto, opterà come standard sul formato SPLITE relegando il formato SHAPE a
subordinato mentre QGIS, ancora per molto tempo, manterrà, come standard, il
formato SHAPE. Questo potrebbe significare che, volendo usare QGIS e GRASS
come programmi distinti ma con gli stessi dati, oltre a dover "imparare" ad
usare due GUI diverse per fare le stesse cose, (fastidioso ma accettabile),
bisognerà anche saper gestire (e temo archiviare) gli stessi dati ora in
SPLITE ora in SHAPE.

Non vorrei sbagliarmi ma per come è strutturato GRASS penso che nel futuro continuerà ad utilizzare il suo formato interno. Già adesso tra l'altro non utilizza direttamente gli shapefile ma li importa.  Cosa diversa per la parte alfanumerica che dalle ultime versioni viene gestita con sqlite e non più dbf. Correggetemi se dico castronerie.

Anche QGIS non ha come formato standard lo shapefile ma tutti i formati gestiti da GDAL/OGR ed ha anche un ottimo supporto per PostGIS e SPLITE.

Luca

[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666+40 iscritti al 5.6.2014

--
http://faunalia.eu/
Sent from mobile, sorry for being short
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666+40 iscritti al 5.6.2014

[Marco]

Ubi maior ...quello che dite è molto rincuorante e ciò mi basta (avevo letto quello che vi ho riferito in un blog dove sono capitato cercando dettagli sull'algoritmo r.lake). E' doveroso aggiungere che il supporto per Splite presente in QGIS non solo è ottimo, ma praticamente rende "indolore" l'interoperabilità tra formati anche ai meno esperti come me.
Vorrei però tornare al tema principale del mio post ...perchè chi lo sa fare, (io non saprei da dove cominciare), non organizza una raccolta fondi per finanziare l'implementazione delle funzioni d'uso di GRASS 7 in QGIS? ...io aderirei subito.

[pcav]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Salve,

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

> Vorrei però tornare al tema principale del mio post ...perchè chi
> lo sa fare, (io non saprei da dove cominciare), non organizza una
> raccolta fondi per finanziare l'implementazione delle funzioni
> d'uso di GRASS 7 in QGIS? ...io aderirei subito.

grazie per l'atteggiamento molto positivo. Ti suggerisco questa procedure:
* cerca uno sviluppatore interessato (in questo caso, la prima scelta
naturale sarebbe Radim Blazek, l'autore originale del plugin, e di
gran parte di GRASS)
* verificata la disponibilita', proponigli di metter su un
crowdfunding, ad es.
https://www.kickstarter.com/projects/41633306/a-christmas-gift-for-qgis-live-layer-effects-for-q

Il tuo sostegno e stimolo nel far partire il progetto puo' essere
molto utile.
Saluti.
- --
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlSpMWUACgkQ/NedwLUzIr568wCfWEgQfRDauHiGuBdLMtHgAOj7
MDQAnA19zmqmhiMCI+XTp3FjmbU+JUxj
=UAhT
-----END PGP SIGNATURE-----
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666+40 iscritti al 5.6.2014

[Maurizio Trevisani]

In ogni caso lo shapefile è un formato primitivo e andrà superato.

Grass è un motore straordinario, ma il fatto che operi esclusivamente
su formati suoi interni potrebbe rivelarsi alla lunga un limite.

Personalmente sono convinto che il futuro possa vedere dilagare
formati Database (sia Postgis sia DB su file per lo scambio, la
cessione, l'uso veloce, magari con la possibilità da PGSQL di
esportare/importare da DB su file).

La scelta di uscire con un Geopackage, che è un DB scemo (la capacità
di elaborazione dati è tutta delegata ad un motore GIS esterno), penso
possa rivelarsi fallimentare, e la leggo come evoluzione dello
shapefile proposto da chi, convinto che lo shp stia morendo, voleva si
un DB, ma un DB che non possedesse autonome capactà di elaborazione
dati (e quindi non potesse risultare, almeno in parte, concorrente dei
prodotti Desktop che le multinazionali che hanno sponsorizzato GPKG).

Personalmente penso che Splite/Rlite possa essere il formato del
prossimo decennio.

E sono convinto che un balzo immenso nel mondo dei GIS si potrebbe
avere se Grass potesse evolvere per operare  nativamente su DB Splite
e Rlite (dove credo ormai ci siano le strutture dati per i dati, la
metainformazione, le vestizioni, la topologia, i formati raster, i
grafi, e non so che altro).

Il ruolo prezioso ed immenso di GDAL e OGR è quello di fare da
"interprete" tra formati diversi, per consentire recupero e
portabilità dei dati. Ma serve una buona strutture dati portabile su
cui i GIS possano operare nativamente: lo shapefile non regge più.


Ciao,
Maurizio



Il 04/01/15, Paolo Cavallini<[hidden email]> ha scritto:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Salve,
>
> Il 03/01/2015 19:33, Marco ha scritto:
>
>> Vorrei però tornare al tema principale del mio post ...perchè chi
>> lo sa fare, (io non saprei da dove cominciare), non organizza una
>> raccolta fondi per finanziare l'implementazione delle funzioni
>> d'uso di GRASS 7 in QGIS? ...io aderirei subito.
>
> grazie per l'atteggiamento molto positivo. Ti suggerisco questa procedure:
> * cerca uno sviluppatore interessato (in questo caso, la prima scelta
> naturale sarebbe Radim Blazek, l'autore originale del plugin, e di
> gran parte di GRASS)
> * verificata la disponibilita', proponigli di metter su un
> crowdfunding, ad es.
> https://www.kickstarter.com/projects/41633306/a-christmas-gift-for-qgis-live-layer-effects-for-q
>
> Il tuo sostegno e stimolo nel far partire il progetto puo' essere
> molto utile.
> Saluti.
> - --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iEYEARECAAYFAlSpMWUACgkQ/NedwLUzIr568wCfWEgQfRDauHiGuBdLMtHgAOj7
> MDQAnA19zmqmhiMCI+XTp3FjmbU+JUxj
> =UAhT
> -----END PGP SIGNATURE-----
> _______________________________________________
> [hidden email]
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 666+40 iscritti al 5.6.2014

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666+40 iscritti al 5.6.2014

[Luca Lanteri-2]

 [...]

Personalmente penso che Splite/Rlite possa essere il formato del
prossimo decennio.

+1

il passaggio da shapefile a geoDB ci porterebbe finalmente nel XXI secolo !

 
Luca

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666+40 iscritti al 5.6.2014

[Andrea Peri]

Io proprio stasera sto smoccolando perche' qgis 2.6.1 non mi vede una
tabella su uno spatialite fatto con la versione 4.2.1-rc1.

Prima di passare al XXI secolo fate una fermata e permettetemi di scendere.

Grazie,

:)


Il 4 gennaio 2015 19:16, Luca Lanteri <[hidden email]> ha scritto:

>  [...]
>>
>> Personalmente penso che Splite/Rlite possa essere il formato del
>> prossimo decennio.
>>
>
> +1
> il passaggio da shapefile a geoDB ci porterebbe finalmente nel XXI secolo !
>
> Luca
>
> _______________________________________________
> [hidden email]
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 666+40 iscritti al 5.6.2014

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
666+40 iscritti al 5.6.2014