L'aspetto validazione in realtà quasi c'e', bisogna solo riammodernare
il modulo "validation" che non è stato usato per qualche anno e
riagganciarlo al WFS-T. Più informazioni su quel modulo si possono
trovare qui:
http://vwfs.refractions.net/
A parte il titolo, la validazione di ArcSDE e' una cosa completamente
differente.
Intanto si riferisce a una validazione sul modello UML da cui e' stato
progettato il GeoDatabase.
Per cui , ad esempio se te hai fatto un modello di una rete fognaria .
E ci vai ad aggiungere un tratto, senza inserirvi uno snodo.
In fase di validazione il sistema ti segnalera' che tale tratto e'
errato e non ne ammettera' il "commit"
(chiamamolo cosi' per capirci, anche se non e' un vero e proprio commit).
Poi pero' va anche chiarito che tutta questa fase di validazione.
Che nei discorsi e a vederla e' molto bella.
Non viene realmente fatta da ArcSDE che in realta' non fa' un bel niente,
ma viene fatta totalmente e completamente dal client ArcGIS che si
collega a ArcSDE.
E le informazioni su come e' fatto il modello del GeoDatabase sono
memorizzate nelle tabelle GDB_..
sul database.
per cui questa validazione e' anche un "pochino lenta", visto che non
avviene a livello di server, ma a livello di client.
Ma tornando al discorso,
su questo piano confrontare ArcSDE e GeoServer e' fuorviante.
Il povero GeoServer non sarebbe in grado di fare una tale validazione.
Ma neanche ArcSDE la fa' 
Caso mai la domanda da porsi e' tra i clients.
esiste un client (udig, gvSIG, ...) che possa applicare un modello e
validarlo sulla base di dati che riceve via WFS ?
Saluti,
--
~~~~~~~~~~~~~~~~~
§ Andrea §
§ Peri §
~~~~~~~~~~~~~~~~~
Andrea Peri ha scritto:
L'aspetto validazione in realtà quasi c'e', bisogna solo riammodernare
il modulo "validation" che non è stato usato per qualche anno e
riagganciarlo al WFS-T. Più informazioni su quel modulo si possono
trovare qui:
http://vwfs.refractions.net/
A parte il titolo, la validazione di ArcSDE e' una cosa completamente
differente.
Intanto si riferisce a una validazione sul modello UML da cui e' stato
progettato il GeoDatabase.
Per cui , ad esempio se te hai fatto un modello di una rete fognaria .
E ci vai ad aggiungere un tratto, senza inserirvi uno snodo.
In fase di validazione il sistema ti segnalera' che tale tratto e'
errato e non ne ammettera' il "commit"
(chiamamolo cosi' per capirci, anche se non e' un vero e proprio commit).
Quindi ti riferisci a validazione a livello di relazioni geometriche
fra tabelle separate?
Non è vero che è impossibile farla, ma è senz'altro scomodo.
Questo tipo di vincolo deve essere programmato ad hoc, la classe che lo
esercita deve sapere in quale feature type devono stare le entità che
deve controllare, farsi a manella le query relative, confrontare
con quello che sta entrando nella transazione corrente, e decidere.
Il modulo di validazione è vecchiotto, ma non ci sono solo validazioni
del tipo attributo < 10 o area(poligono) < 10.000, ma anche cose come:
- le geometrie inseriti deve stare entro (o al di fuori) di un poligono
pre-specificato
- le linee non si possono intersecare (intersezione secca, il contatto
sugli estremi è ammesso)
Quel che voglio dire è che nella API di validazione non ci sono vincoli
specifici su quello che il validatore deve fare, questo riceve o la
feature che viene modificata o l'insieme delle tabelle che sono state
modificate e fa il controllo che gli pare.
Detto questo, se hai un database spaziale alle spalle gli stessi
controlli si possono fare in uno o più trigger, e probabilmente
in modo più efficiente (anche se non portabile).
Ciao
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Detto questo, se hai un database spaziale alle spalle gli stessi
controlli si possono fare in uno o più trigger, e probabilmente
in modo più efficiente (anche se non portabile).
Infatti per fare le cose per bene questo genere di cose si dovrebbero
fare facendo in modo che al modello venga a corrispondere un insieme
di trigger,sequece e stored-procedure che verifichino al volo le
regole imposte dal modello.
Ovviamente si capisce anche che cosi' facendo sarebbe piu' difficile
fare un sistema multi-dbms e non potrebbe senz'altro funzionare su
access (che non ha trigger).
Per questo il geodatabase non fa' assolutamente uso di trigger,
sequence, e store-procedure.
Ma demanda tutto al client (arcgis)
Per cui riesce piu' facilmente a supportare molti dbms e anche access.
Saluti,
2008/11/20 Andrea Aime <aaime@opengeo.org>:
Andrea Peri ha scritto:
L'aspetto validazione in realtà quasi c'e', bisogna solo riammodernare
il modulo "validation" che non è stato usato per qualche anno e
riagganciarlo al WFS-T. Più informazioni su quel modulo si possono
trovare qui:
http://vwfs.refractions.net/
A parte il titolo, la validazione di ArcSDE e' una cosa completamente
differente.
Intanto si riferisce a una validazione sul modello UML da cui e' stato
progettato il GeoDatabase.
Per cui , ad esempio se te hai fatto un modello di una rete fognaria .
E ci vai ad aggiungere un tratto, senza inserirvi uno snodo.
In fase di validazione il sistema ti segnalera' che tale tratto e'
errato e non ne ammettera' il "commit"
(chiamamolo cosi' per capirci, anche se non e' un vero e proprio commit).
Quindi ti riferisci a validazione a livello di relazioni geometriche
fra tabelle separate?
Non è vero che è impossibile farla, ma è senz'altro scomodo.
Questo tipo di vincolo deve essere programmato ad hoc, la classe che lo
esercita deve sapere in quale feature type devono stare le entità che
deve controllare, farsi a manella le query relative, confrontare
con quello che sta entrando nella transazione corrente, e decidere.
Il modulo di validazione è vecchiotto, ma non ci sono solo validazioni
del tipo attributo < 10 o area(poligono) < 10.000, ma anche cose come:
- le geometrie inseriti deve stare entro (o al di fuori) di un poligono
pre-specificato
- le linee non si possono intersecare (intersezione secca, il contatto
sugli estremi è ammesso)
Quel che voglio dire è che nella API di validazione non ci sono vincoli
specifici su quello che il validatore deve fare, questo riceve o la
feature che viene modificata o l'insieme delle tabelle che sono state
modificate e fa il controllo che gli pare.
Detto questo, se hai un database spaziale alle spalle gli stessi
controlli si possono fare in uno o più trigger, e probabilmente
in modo più efficiente (anche se non portabile).
Ciao
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
--
~~~~~~~~~~~~~~~~~
§ Andrea §
§ Peri §
~~~~~~~~~~~~~~~~~