>Oggi ho finalmente trovato uno scampolo di tempo libero per fare
>qualche test pratico; chi eventualmente fosse interessato all'argomento
>puo' leggersi il mio report preliminare:
>
[>https://www.gaia-gis.it/fossil/libspatialite/wiki?name=VirtualOGR](https://www.gaia-gis.it/fossil/libspatialite/wiki?name=VirtualOGR)
Alessandro,
Ho letto il tuo documento, in effetti si prospettano scenari e impieghi molto interessanti.
Peor’ io con la mente corro subito ai nostri impieghi.
E quindi non capisco come si riescono a passare gli eventuali parametri. Certi drivers richiedono dei parametri per funzionare.
Ad esempio , se volessi collegarmi con un file GML topologico (ti ricorda niente ?) come gli passo tutti i parametri per dirgli come comportarsi per risolvere le faces.
Hai avuto modo di testare questo aspetto ?
–
Andrea Peri
. . . . . . . . .
qwerty àèìòù
On Sat, 3 Nov 2012 20:52:16 +0100, Andrea Peri wrote:
Ho letto il tuo documento, in effetti si prospettano scenari e
impieghi molto interessanti.
Peor' io con la mente corro subito ai nostri impieghi.
E quindi non capisco come si riescono a passare gli eventuali
parametri. Certi drivers richiedono dei parametri per funzionare.
Ad esempio , se volessi collegarmi con un file GML topologico (ti
ricorda niente ?)
come gli passo tutti i parametri per dirgli come
comportarsi per risolvere le faces.
Hai avuto modo di testare questo aspetto ?
Andrea,
per quanto ho avuto occasione di vedere VirtualOGR attualmente non
prevede la possibilita' di passare nessun parametro extra ad OGR.
ed e' un vero peccato, perche' in molti casi invece specificare qualche
opzione extra e' assolutamente indispensabile per riuscire ad ottenere
buoni risultati.
a lume di naso non parrebbe affatto impossibile: basterebbe semplicemente
introdurre un ulteriore parametro (una stringa di testo) destinata a
contenere tutte le eventuali opzioni da passare al driver.
sicuramente VirtualOGR e' ancora una tecnologia molto "verde" (nel senso
che e' immatura); in pratica quello di ieri e' stato il primo annuncio
destinato a suscitare un po' di interesse attorno al progetto.
magari convincendo qualche "power user" a farsi un po' di test 
immagino che qualsiasi critica, osservazione etc saldamente fondata su
alcuni casi d'uso concreti sarebbe sicuramente molto utile per arrivare
rapidamente ad una messa a punto definitiva; dopo tutto ancora il progetto
e' in fase beta, quindi i margini di aggiustamento ci sono tutti.
del resto mi pare che Even Rouault e' sempre molto disponibile ed attento
a prestare attenzione ai suggerimenti.
ciao Sandro
--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.
immagino che qualsiasi critica, osservazione etc saldamente fondata su
alcuni casi d’uso concreti sarebbe sicuramente molto utile per arrivare
rapidamente ad una messa a punto definitiva; dopo tutto ancora il progetto
e’ in fase beta, quindi i margini di aggiustamento ci sono tutti.
L’annuncio era sulla lista gdal ?
Una ultima domanda:
con VirtualOGR, driver permettendo, è possibile anche scrivere sulla tabella virtuale ?
Andrea.
Il giorno 04 novembre 2012 10:01, <a.furieri@lqt.it> ha scritto:
On Sat, 3 Nov 2012 20:52:16 +0100, Andrea Peri wrote:
Ho letto il tuo documento, in effetti si prospettano scenari e
impieghi molto interessanti.
Peor’ io con la mente corro subito ai nostri impieghi.
E quindi non capisco come si riescono a passare gli eventuali
parametri. Certi drivers richiedono dei parametri per funzionare.
Ad esempio , se volessi collegarmi con un file GML topologico (ti
ricorda niente ?)
come gli passo tutti i parametri per dirgli come
comportarsi per risolvere le faces.
Hai avuto modo di testare questo aspetto ?
Andrea,
per quanto ho avuto occasione di vedere VirtualOGR attualmente non
prevede la possibilita’ di passare nessun parametro extra ad OGR.
ed e’ un vero peccato, perche’ in molti casi invece specificare qualche
opzione extra e’ assolutamente indispensabile per riuscire ad ottenere
buoni risultati.
a lume di naso non parrebbe affatto impossibile: basterebbe semplicemente
introdurre un ulteriore parametro (una stringa di testo) destinata a
contenere tutte le eventuali opzioni da passare al driver.
sicuramente VirtualOGR e’ ancora una tecnologia molto “verde” (nel senso
che e’ immatura); in pratica quello di ieri e’ stato il primo annuncio
destinato a suscitare un po’ di interesse attorno al progetto.
magari convincendo qualche “power user” a farsi un po’ di test
immagino che qualsiasi critica, osservazione etc saldamente fondata su
alcuni casi d’uso concreti sarebbe sicuramente molto utile per arrivare
rapidamente ad una messa a punto definitiva; dopo tutto ancora il progetto
e’ in fase beta, quindi i margini di aggiustamento ci sono tutti.
del resto mi pare che Even Rouault e’ sempre molto disponibile ed attento
a prestare attenzione ai suggerimenti.
ciao Sandro
–
Il messaggio e’ stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e’
risultato non infetto.
–
Andrea Peri
. . . . . . . . .
qwerty àèìòù
On Sun, 4 Nov 2012 10:14:52 +0100, Andrea Peri wrote:
L'annuncio era sulla lista gdal ?
si; io personalmente l'ho lanciato sulla ML di SpatiaLite (e su gfoss.it,
ovviamente). qualche ora dopo Even l'ha rimbalzato sulla gdal-dev:
http://osgeo-org.1560.n6.nabble.com/gdal-dev-Trans-SpatiaLite-Users-2013-technology-preview-td5013728.html
Una ultima domanda:
con VirtualOGR, driver permettendo, è possibile anche scrivere sulla
tabella virtuale ?
si: ho appena fatto un test su PostGIS.
a) prima mi sono dovuto creare una tavola vuota con pgAdminIII
b) poi ho usato SpatiaLite GUI con VirtualOGR per trasferire una
tavola da splite a postgis: funziona
c) pero' noto anche che VirtualOGR (almeno su postgis) "nasconde"
tutte le colonne Primary Key (nel senso che proprio le rende
invisibili). e quindi immagino che necessariamente:
- o la tavola target deve essere priva di PK (il caso che ho testato).
- oppure deve avere per forza una PK di tipo auto-incrementale
insomma, sicuramente ci sono diversi aspetti "ruvidi" che meriterebbe la
pena di sistemare e raffinare.
ma la base di implementazione si conferma molto promettente.
ciao Sandro
--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.
Alessandro,
ancora grazie.
Tra l’altro Roualt nel frattempo ha risposto che i parametri extra si mettono a livello di variabili di ambiente.
Alessandro.
A tuo parere quando ci sarà un buon rastrlite, la virtual-ogr potrà essere usata anche con rasterlite ?
Il giorno 04 novembre 2012 10:46, <a.furieri@lqt.it> ha scritto:
On Sun, 4 Nov 2012 10:14:52 +0100, Andrea Peri wrote:
L’annuncio era sulla lista gdal ?
si; io personalmente l’ho lanciato sulla ML di SpatiaLite (e su gfoss.it,
ovviamente). qualche ora dopo Even l’ha rimbalzato sulla gdal-dev:
http://osgeo-org.1560.n6.nabble.com/gdal-dev-Trans-SpatiaLite-Users-2013-technology-preview-td5013728.html
Una ultima domanda:
con VirtualOGR, driver permettendo, è possibile anche scrivere sulla
tabella virtuale ?
si: ho appena fatto un test su PostGIS.
a) prima mi sono dovuto creare una tavola vuota con pgAdminIII
b) poi ho usato SpatiaLite GUI con VirtualOGR per trasferire una
tavola da splite a postgis: funziona
c) pero’ noto anche che VirtualOGR (almeno su postgis) “nasconde”
tutte le colonne Primary Key (nel senso che proprio le rende
invisibili). e quindi immagino che necessariamente:
- o la tavola target deve essere priva di PK (il caso che ho testato).
- oppure deve avere per forza una PK di tipo auto-incrementale
insomma, sicuramente ci sono diversi aspetti “ruvidi” che meriterebbe la
pena di sistemare e raffinare.
ma la base di implementazione si conferma molto promettente.
ciao Sandro
–
Il messaggio e’ stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e’
risultato non infetto.
–
Andrea Peri
. . . . . . . . .
qwerty àèìòù
On Sun, 4 Nov 2012 12:00:18 +0100, Andrea Peri wrote:
Alessandro.
A tuo parere quando ci sarà un buon rastrlite, la virtual-ogr potrà
essere usata anche con rasterlite ?
allo stato attuale non saprei dire: come noto libgdal e' praticamente
"affettata in due". da una parte abbiamo GDAL "puro" che supporta
i formati raster, dall'altra OGR che supporta i vectors ed i DBMS.
VirtualOGR (come dice il nome) e' un componente di OGR, non ha nulla
a che vedere con GDAL. e purtroppo il driver per rasterlite fa parte
proprio di GDAL.
insomma, la questione e' tutta da studiare e da valutare; dopo tutto
rasterlite e' "anfibia", visto che e' sia raster che DBMS al tempo
stesso. non la vedo del tutto impossibile, ma neppure troppo facile
ciao Sandro
--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.