Riguardo il secondo punto, condivido quanto dice Diego sulla necessità
di essere svincolati dal db, percui i sistemi di validazione non
dovrebbero essere basati su procedure db-side. Personalmente condivido
l'architettura Esri: ArcSDE "fornisce" il modello (mantenuto in
qualche forma nel DB), il client [1] si occupa di validare. La stessa
cosa la vedrei anche per la gestione del versioning. Adesso Geoserver
offre un modulo (WFSV) per un Postgis configurato ad-hoc... L'optimum
sarebbe riuscire a gestirlo ad un livello di astrazione maggiore.
Concorderei anche io che non ha senso riscriversi un client che faccia
quello che gia' fa' ArcGIS.
La discussione era filosofica.
Infatti se se uno "vuole" e "puole" lo potrebbe fare.
Diverse e' dire non e' possibile farlo.
Comunque per passare alla seconda parte del discorso,
Io non penso che convenga farla lato client.
E' piu' semplice da sviluppare senz'altro.
Ma poi lo paghi in efficienza.
Infatti quando dicevo magnanimamente che era un "pochino lento" , e
Diego ha puntualizzato con un "mostruosamente.."
Va chiarito che la causa di tale lentezza e' da ricercarsi
principalmente nella scelta tecnologica di fare la validita' a livello
di client, e non come si potrebbe pensare perche' sono poco esperti i
programmatori esri, che anzi sembrano dei molto capaci.
infatti lavorando al ivello client non puoi usare tutti gli strumenti
che il DBMS ti mette a disposizione (trigger e stored-procedure) e per
giunta sei costretto anche a operare proceduralmente per tenere la
compatibilita' con tutti i vari DBMS.
Tutto questo penalizza molto la velocita' di esecuzione.
Infatti se si lavora a livello client ci si scontra inevitabilmente
con dei colli di bottiglia invalicabili.
La rete, il caricamento delle features sul client prima che possa
cominciare a eseguire le varie intersezioni spaziali, overlaps, e
quant'altro gli serve per validare la feature.
Per questo il sistema ESRI e' pensato tipicamente per l'editing "minuto"
Cioe' per l'inserimento di una singola feature.
Mi spiego meglio .
Se hai un sistema e vai a inserirci una singola feature, ad esempio un pozzo.
Poi lo puoi validare, la validazione sara' un qualcosa che richiede
pochi secondi, massimo 1 minutino.
Pero', per lavorare cosi' devi sempre avere il client ArcGIS in
contatto con l' ArcSDE.
E quindi se pensi di sviluppare il lavoro affidandolo a un soggetto
esterno per poi validarne l'operato quando ti ritorna i risultati....
E supponi che il risultato sia una intera provincia.
Non e' da escludere che l'esecuzione della validazione se tutto va
bene, possa richiedere anche qualche giorno di esecuzione.
Come sottoprodotto della logica di validazione poi vi e' anche il
problema che non ha senso elencare tutte le features non valide.
Ma occorre svilupparla sequenzialmente.
Per cui se ad esempio nel tuo archivio sono 4 feature non valide.
Alla prima feature non valida il sistema si ferma segnalandotela.
E finche' non la hai rimessa a posto lui non passa oltre per elencarti
le successive.
ma questo e' una conseguenza della logica operativa e non della scelta
della validazione sul client.
Per superarla occorrerebbe implementare non solo la validazione, ma
anche la risoluzione automatica del problema, ovvero il sistema
corregge automaticamente ....
( un altro film ....)
Saluti,
Il 20 novembre 2008 12.33, G. Allegri <giohappy@gmail.com> ha scritto:
in sintesi, mi sembra che siano sorte 2 questioni principali:
1 - come/se offrire strumenti per permettere a client desktop OS di
gestire e accedere alle funzionalità offerte da ArcSDE
2 - sviluppare alternative ad ArcSDE
Premetto: scusate se scriverò castronerie! 
Parlo più da un punto di
vista dell'utente che non da sviluppatore enterprise!
Pur comprendendo l'importanza dell'interoperabilità e
dell'integrazione, sinceramente ritengo prioritario il secondo. Non mi
sembra il caso di spendere le poche o tante risorse a disposizione per
riprodurre ciò che ArcGIS fa rispetto ad ArcSDE, altrimenti si finisce
per incatenarci a quest'ultimo. Lo dico perché delle volte è emersa
questa direzione...
Riguardo il secondo punto, condivido quanto dice Diego sulla necessità
di essere svincolati dal db, percui i sistemi di validazione non
dovrebbero essere basati su procedure db-side. Personalmente condivido
l'architettura Esri: ArcSDE "fornisce" il modello (mantenuto in
qualche forma nel DB), il client [1] si occupa di validare. La stessa
cosa la vedrei anche per la gestione del versioning. Adesso Geoserver
offre un modulo (WFSV) per un Postgis configurato ad-hoc... L'optimum
sarebbe riuscire a gestirlo ad un livello di astrazione maggiore.
[1] Nel fantastico mondo dei sogni, io mi immagino una sorta di
libreria/plugin dedicata a questo, da poter "wrappare" nei diversi
client.
Avrò detto molte banalità. E' solo per condividere un po' delle
richieste che via via mi vengono fatte sul tema...
2008/11/20 Diego Guidi <diegoguidi@gmail.com>:
Il sorgente è a disposizione, per quanto ne posso capire basta
implementare il support per queste look up table.
Non vedo un problema strutturale, solo la mancanza di qualcuno
che abbia insieme la capacità e l'interesse per realizzare questa
funzione.
Giustissimo
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@faunalia.com
http://www.faunalia.com/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.
--
~~~~~~~~~~~~~~~~~
§ Andrea §
§ Peri §
~~~~~~~~~~~~~~~~~
allora vuoi la guerra!