> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>: >>> 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 >> [email protected] >> 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 § ~~~~~~~~~~~~~~~~~ _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [email protected] 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.
