[Gfoss] PostGres vs. Oracle

Local Chapters GFOSS.it
1

La "sdo_topo_geometry" e' il tipo di dato che oracle usa per
memorizzare una forma geometrica in un contenitore con topologia.

Purtroppo (non capiro' mai perche')
dopo aver fatto il contenitore, si sono "dimenticati" di fare le due
funzioni principali:
"clean" e "build".

Per cui i dati che si memorizzano devono gia' essere corretti dal
punto di vista topologico.
Perche' altrimenti oracle non li accetta dentro una struttura sdo_topo_geometry.

La mancanza dei comandi di "clean" e "build" per ripulire e costruire
la topologia,
rendono abbastanza complicato popolare una sdo_topo_geometry.
Con la 10g release 1 le strutture edge , face e node, andavano
popolate singolarmente e questo complicava ancora di piu' le cose.
Con la 10g release 2 e' stata introdotta una funzione che consente di
caricare in un colpo solo edge, node e face. Questo facilita il
compito, pero' se il dato che si carica non e' corretto
topologicamente gia' in partenza, oracle lo rifiuta (nella
sdo_topo_geometry).

Sigh... :frowning:

Ovviamente nessuno vieta di implementare una clean/build con le api di
oracle che sono abbastanza complete, ma ovviamente non e' la stessa
cosa.

Su questo punto non so' come si comporta postgis.

Ma comunque temo che si riproponga il mdesimo schema: una struttura
topologica, senza li strumenti per rendere topologico un archivio.

Andrea.

--
~~~~~~~~~~~~~~~~~
§ Andrea §
§ Peri §
~~~~~~~~~~~~~~~~~

2

Premetto che non ho alcuna esperienza con strutture topologiche all’interno di DB, però mi chiedo se sia davvero auspicabile che i DBMS si “assumessero la responsabilità” di creare e pulire le topologie. Per l’esperienza fatta con i GIS queste procedure a volte sono molto delicate, e richiedono una verifica dei risultati perché non è raro che vengano prodotti artefatti (topologicamente corretti) che non corrispondono alla struttura reale degli oggetti.
In altre parole, non è più corretto che la topologia venga controllata e validata prima di chiamare in causa i DBMS?

Giovanni

2008/2/12, Andrea Peri <peri.rtoscana@gmail.com>:

La “sdo_topo_geometry” e’ il tipo di dato che oracle usa per
memorizzare una forma geometrica in un contenitore con topologia.

Purtroppo (non capiro’ mai perche’)
dopo aver fatto il contenitore, si sono “dimenticati” di fare le due
funzioni principali:
“clean” e “build”.

Per cui i dati che si memorizzano devono gia’ essere corretti dal
punto di vista topologico.
Perche’ altrimenti oracle non li accetta dentro una struttura sdo_topo_geometry.

La mancanza dei comandi di “clean” e “build” per ripulire e costruire
la topologia,
rendono abbastanza complicato popolare una sdo_topo_geometry.
Con la 10g release 1 le strutture edge , face e node, andavano
popolate singolarmente e questo complicava ancora di piu’ le cose.
Con la 10g release 2 e’ stata introdotta una funzione che consente di
caricare in un colpo solo edge, node e face. Questo facilita il
compito, pero’ se il dato che si carica non e’ corretto
topologicamente gia’ in partenza, oracle lo rifiuta (nella
sdo_topo_geometry).

Sigh… :frowning:

Ovviamente nessuno vieta di implementare una clean/build con le api di
oracle che sono abbastanza complete, ma ovviamente non e’ la stessa
cosa.

Su questo punto non so’ come si comporta postgis.

Ma comunque temo che si riproponga il mdesimo schema: una struttura
topologica, senza li strumenti per rendere topologico un archivio.

Andrea.

–

§ Andrea §
§ Peri §

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.

3

Giusta osservazione, in effetti parrebbe proprio che la pensino come te.

Pero', secondo me', in questo compiono una ingenuita, dettata forse da un approccio troppo informatico al problema.

In effetti, sembra proprio che i tecnici di oracle si siano immaginati che chi lavora nei gis sia come chi lavora con i DB relazionali, e quindi immaginano che avvenga come negli archivi relazionali tradizionali. Si carica il dato quando le relazioni FK sono tutte gia' state sistemate, e non si immagina che dentro il DBMS ci sia un qualcosa che scorpori un archivio flat in un archivio relazionale. Giustissimo, nei db relazionali non avrebbe il minimo senso pratico una cosa del genere.

Ma nei GIS si opera in maniera differente.

In arcinfo non si costruisce la coverage dopo che tutto l'archivio (ad esempioo in shapefile) e' stato editato e corretto, considerando la coverage come l'ultimo atto di un processo produttivo di editing. Una sorta di fissamento del risultato.

Bensi' , la costruzione della coverage e' una delle prime fasi, cosi' si sfrutta la proprieta' topologiche del contenitore coverage per rimuovere e/o rimuovere subito le incongruenze topologiche piu' marcate, e poi si scende nel dettaglio raffinato e si aggiustano le cose.

Partendo da questo modo di procedere e volendo usare il DBMS al posto della coverage, il primo passo e' caricare l'archivio in una struttura topologica, e quindi serve qualcosa che ce la sistemi dentro, rimuovendo e aggiustando le incongruita' topologiche.

Andrea.

G. Allegri ha scritto:

Premetto che non ho alcuna esperienza con strutture topologiche all'interno
di DB, però mi chiedo se sia davvero auspicabile che i DBMS si "assumessero
la responsabilità" di creare e pulire le topologie. Per l'esperienza fatta
con i GIS queste procedure a volte sono molto delicate, e richiedono una
verifica dei risultati perché non è raro che vengano prodotti artefatti
(topologicamente corretti) che non corrispondono alla struttura reale degli
oggetti.
In altre parole, non è più corretto che la topologia venga controllata e
validata prima di chiamare in causa i DBMS?

Giovanni