Ciao a tutti,
da qualche giorno facendo delle richieste WMS al portale cartografico nazionale sui tile compare un logo del geoportale. Vi risulta questa novità?
Ciao
michele
esempio richiesta:
On Wed, Jul 28, 2010 at 09:23:46AM +0200, tape2m@virgilio.it wrote:
da qualche giorno facendo delle richieste WMS al portale
cartografico nazionale sui tile compare un logo del geoportale.
Vi risulta questa novità?
È una novità recente. Da quando il progetto OpenStreetMap ha
iniziato ad usare il PCN, quelli del Ministero sono diventati un
po' paranoici ed hanno paura che qualcuno gli copi i dati
illegalmente.
--
Niccolo Rigacci
Firenze - Italy
Non so se l'avete notato, ma dopo svariati mesi di
attesa finalmente è uscita da qualche giorno una
release nuova di SQLite (3.7.0)
Hanno fatto decisamente bene a prendersela con
tutta calma, visto che hanno riscritto praticamente
da zero tutto quanto il motore transazionale.
ora non usano più un banale logfile: ora usano un
WAL [write ahead logfile] che sembra copiato pari
pari da quello di PostgreSQL: in più usano estensivamente
la shared memory per sincronizzare e semaforizzare i
vari processi che tentano di accedere al medesimo DB.
"Si, ma ... a noi che ce ne frega ? in pratica cosa significa ?"
significa che mentre prima SQLite era un po' lentino
in scrittura (un pelo più lento di PostgreSQL p.es.),
ora vola sparato alla velocità della luce.
le prime prove che sto facendo con SpatiaLite mi hanno
lasciato letteralmente a bocca aperta 
così a prima impressione "a pelle" direi che ora SQLite
si mangia PostgreSQL e MySQL in un sol boccone 
ciao Sandro
Il 28/07/2010 21:12, a.furieri@lqt.it ha scritto:
le prime prove che sto facendo con SpatiaLite mi hanno
lasciato letteralmente a bocca aperta
qundi per SpatiaLite e RasterLite non cambia niente, a parte le performances? Le API
sono le stesse?
Saluti.
--
Paolo Cavallini: http://www.faunalia.it/pc
On Thu, 29 Jul 2010 07:59:07 +0200, Paolo Cavallini wrote
qundi per SpatiaLite e RasterLite non cambia niente, a parte le
performances? Le API sono le stesse?
API assolutamente identiche: non è cambiato neppure un peluzzo.
- by-default il DB viene creato "old style"
N.B: in questa modalità può essere letto/scritto anche
usando qualsiasi versione precedente di sqlite
- per attivare la modalità WAL occorre eseguire una direttiva:
PRAGMA journal_file=wal
* la direttiva è permanente (modifica l'header del DB)
* se poi provi ad aprire un DB-WAL con una vecchia versione di
SQLite esce immediatamente un errore fatale:
"DB corrotto oppure criptato, impossibile accedere"
- per ripristinare la compatibilità a ritroso basta semplicemente
aprire il DB con la 3.7.0 e lanciare:
PRAGMA journal_file=delete
insomma, fare lo switching tra le due modalità è semplicissimo
e praticamente istantaneo.
direi che WAL è abbastanza più avido di risorse: occupa più
RAM, e genera dei logfiles più grossi.
ma il vantaggio enorme è che ora (con WAL) finalmente SQLite
supporta in modo decoroso la concorrenza degli accessi.
prima era praticamente impossibile fare lavorare due o più
processi simultaneamente sul medesimo DB: prima o poi usciva
fuori il famigerato messaggio:
"database is locked, transaction aborted"
ora invece (con WAL) *enne* processi possono accedere
simultaneamente in lettura senza interferenze: e
contemporaneamenteun un unico processo può lavorare
tranquillamente in scrittura.
I dati inseriti/modificati/eliminati dal "processo scrittore"
resteranno comunque invisibili per gli altri utenti fino a
quando la transazione non esegue il COMMIT.
Se poi serve assolutamente supportare due o più processi di
scrittura concomitanti, allora sicuramente è il caso di passare
a PostgreSQL
Insomma, ora SQLite non è più ristretto al ruolo di "personal
DB" per usi strettamente desktop.
IMHO diventa più che ragionevole ipotizzare l'impiego di
SQLite (e SpatiaLite) p.es. anche in contesti WEB server,
dove tipicamente "si legge tanto" ma "si scrive pochino".
Penso in particolare ai server WFS / WFS-T, che parrebbero
fatti apposta per gestire un approccio basato su enne threads
di lettura ed un unico thread di scrittura.
ciao Sandro
Magari per qualcuno di voi questa notizia potrebbe risultare
utile ed interessante.
Danil Marcotte ha rilasciato un plugin AutoLISP che
consente di visualizzare un DB spatialite su AutoCAD:
ma credo di capire che funziona anche su qualsiasi
altro CAD che supporta AutoLISP
http://groups.google.com/group/spatialite-users/browse_thread/thread/3caa785c0994de3e
ciao Sandro
Ciao Sandro,
grazie per l'ottima review. Mi fa piacere vedere tanta evoluzione in
Sqlite, e la necessità di qualcosa simil-WAL era proprio sentita... e
vedere che hanno implementato proprio WAL va oltre le aspettative!
Domanda (non so se mi sono perso qualche passaggio): quando pensi di
rendere disponibile Spatialite su Sqlite 3.7?
giovanni
Il 29 luglio 2010 09.15, <a.furieri@lqt.it> ha scritto:
On Thu, 29 Jul 2010 07:59:07 +0200, Paolo Cavallini wrote
qundi per SpatiaLite e RasterLite non cambia niente, a parte le
performances? Le API sono le stesse?API assolutamente identiche: non è cambiato neppure un peluzzo.
- by-default il DB viene creato "old style"
N.B: in questa modalità può essere letto/scritto anche
usando qualsiasi versione precedente di sqlite- per attivare la modalità WAL occorre eseguire una direttiva:
PRAGMA journal_file=wal
* la direttiva è permanente (modifica l'header del DB)
* se poi provi ad aprire un DB-WAL con una vecchia versione di
SQLite esce immediatamente un errore fatale:
"DB corrotto oppure criptato, impossibile accedere"- per ripristinare la compatibilità a ritroso basta semplicemente
aprire il DB con la 3.7.0 e lanciare:
PRAGMA journal_file=deleteinsomma, fare lo switching tra le due modalità è semplicissimo
e praticamente istantaneo.
direi che WAL è abbastanza più avido di risorse: occupa più
RAM, e genera dei logfiles più grossi.ma il vantaggio enorme è che ora (con WAL) finalmente SQLite
supporta in modo decoroso la concorrenza degli accessi.prima era praticamente impossibile fare lavorare due o più
processi simultaneamente sul medesimo DB: prima o poi usciva
fuori il famigerato messaggio:
"database is locked, transaction aborted"ora invece (con WAL) *enne* processi possono accedere
simultaneamente in lettura senza interferenze: e
contemporaneamenteun un unico processo può lavorare
tranquillamente in scrittura.
I dati inseriti/modificati/eliminati dal "processo scrittore"
resteranno comunque invisibili per gli altri utenti fino a
quando la transazione non esegue il COMMIT.Se poi serve assolutamente supportare due o più processi di
scrittura concomitanti, allora sicuramente è il caso di passare
a PostgreSQLInsomma, ora SQLite non è più ristretto al ruolo di "personal
DB" per usi strettamente desktop.
IMHO diventa più che ragionevole ipotizzare l'impiego di
SQLite (e SpatiaLite) p.es. anche in contesti WEB server,
dove tipicamente "si legge tanto" ma "si scrive pochino".Penso in particolare ai server WFS / WFS-T, che parrebbero
fatti apposta per gestire un approccio basato su enne threads
di lettura ed un unico thread di scrittura.ciao Sandro
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@faunalia.it
http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
460 iscritti al 15.7.2010
Ciao Sandro,
Domanda (non so se mi sono perso qualche passaggio): quando pensi di
rendere disponibile Spatialite su Sqlite 3.7?
As soon as possible: ci sto giusto lavorando sopra.
appena pronti ... via !!!
ciao Sandro