tabelle tipizzate in Postgres di schede descrittive

[gissara]

CONTENTS DELETED

The author has deleted this message.

[Marco Li Volsi]

Ciao.
Non sono sicuro di aver capito quali sono le classi di oggetti e le
relazioni tra loro, quindi esporrò una mia opinione in generale.

Quando esistono due modalità di esplicitare la stessa relazione fra due
classi di oggetti c'è sempre il pericolo che queste due modalità siano
in contrasto. Nel tuo caso, le due modalità sono una "topologica" (join
spaziale) e l'altra "numerica" (chiave esterna), i valori potrebbero non
essere coerenti (a meno di meccanismi di controllo o correzione
automatica... che immagino implementati mediante trigger) e definire due
relazioni completamente diverse.

Spero di aver scritto in un italiano comprensibile :-)

Saluti.


Il 17/09/2016 15:15, gissara ha scritto:

> Ciao a tutti!  creato un db con diversi strati informativi fra cui
> fabbricati, edificato suddiviso per classe di vincolo, a questi ultimi
> associo un nuovo livello con delle schede descrittive di alcuni edifici. Io
> vorrei rendere questo sistema tipizzato e flessibile nell'inserimento dei
> dati di rilievo, concettualemtne andrebbe divisa la scheda in 4 parti: la
> generale di inquadramento topografico dell'edificio e la parte descrittiva
> degli elementi strutturali e descrittivi, infine gli allegato. Io avevo
> creato una vista con join spaziale delle tabelle rispetto al layer da dove
> estraggo la geometria. In questo cosa mi consigliate di fare anche una
> foreign key per rafforzare la relazione 1:n?
> Grazie mille.
>
> --
> View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/tabelle-tipizzate-in-Postgres-di-schede-descrittive-tp7596183.html
> Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.
> _______________________________________________
> [hidden email]
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
> 807 iscritti al 31/03/2016

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
807 iscritti al 31/03/2016

[gissara]

CONTENTS DELETED

The author has deleted this message.

[Amedeo Fadini]

Ciao Lucia e benvenuta in lista...

Il 18 settembre 2016 19:57, gissara <[hidden email]> ha scritto:
> Ciao,
>
> Grazie mille per l'aiuto. Capisco ciò che intende ma non sono sicura di
> poter definire dei trigger adeguati per avitare delle conflittualità. Per il
> join spaziale ho usato il campo denominazione dello shape fabbricati, da cui
> mi dovrei estrarre le informazioni geometriche, a questo ho anche agganciato
> le tabelle delle schede descrittive.

In un primo tempo ho inteso "join spaziale" come un collegamento solo
tramite relazione spaziale: es. un punto che rappresenta la scheda da
rilievo correlata al fabbricato tramite una funzione ST_Contains().
Ora mi par di capire che hai una chiave esterna, ovvero un campo della
scheda descrittiva che fa riferimento allo shape fabbricati.

Non ho capito bene gli strumenti che stai usando: il consiglio è di
importare tutto in un database, magari Spatialite che è contenuto in
un unico file, poi potrai visualizzare e gestire tutto agevolmente da
QGIS; per creare il db sempre meglio la spatialite gui [0]:

Anch'io ci vedo due ordini di problemi:
 - la definizione di chiavi robuste che non cambino nel tempo (legate
alla stessa definizione di entità fabbricato)
 - evitare la moltiplicazione di tabelle

Non so bene la struttura dello shapefile fabbricati ma un campo che si
chiama "denominazione" non mi ispira dei valori univoci e immutabili
nel tempo. Se c'è un codice o un numero (magari a partire dalla ctr)
meglio utilizzare quello o al limite la ID della feature (se hai un
poligono o multipoligono per ciascun fabbricato)

Per i dati dell'analisi sicuramente conviene creare delle tabella con
le informazioni ricorrenti da correlare con una relazione molti a
molti, ad esempio immagino una tabella con la lista degli elementi
strutturali o architettonici in cui avere un nome breve e una
descrizione, per evitare di ricopiare mille volte nella tabella schede
cose tipo "copertura a due falde in legno sostenuta da capriate alla
lombarda..." Anche le informazioni realative ai materiali e allo stato
di conservazione le vedrei bene ciascuna su una tabella in maniera
tale che compilando la scheda non ci siano ripetizioni. Anceh senza
creare dei trigger, è opportuno che siano definite bene le chiavi
esterne.. vedi qui [1] e qui [2] alcuni concetti di base se non sei
già esperta di database.

La maschera di inserimento/visualizzazione può esser un po'
complicata, e devo ammettere che io non ho mai utilizzato
il widget "relazione" in QGIS ma dovrei falro presto...

Spero di non aver creato confusione.. facci sapere come procede.

Amedeo Fadini

[0] https://www.gaia-gis.it/fossil/spatialite_gui/index
[1] https://www.postgresql.org/docs/9.4/static/ddl-constraints.html#DDL-CONSTRAINTS-PRIMARY-KEYS
[2] https://www.gaia-gis.it/gaia-sins/spatialite-cookbook/html/create-db.html
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
807 iscritti al 31/03/2016

[Andrea Peri]

Se può far comodo come esempio:
Nel plugin Omero , in una sua cartella è disponibile uno schema entity
relationships di una base dati completa per xemsire edifici anche dal.punto
di vista architettonico e con elementi strutturali.
Compresi i file sql per definirla creando tabelle e relazioni dentro un db
spatialite.

Il plugin Omero è per popolarla, ma è complicato da usare.
Però la base dati di riferimento potrebbe essere un buon punto di partenza
per chi deve fare roba strutturata su edifici architettonico.
Inoltre è previsto una forma di chiave univoca sufficientemente robusta .

Il 19 set 2016 00:05, "Amedeo Fadini" <[hidden email]> ha scritto:

> Ciao Lucia e benvenuta in lista...
>
> Il 18 settembre 2016 19:57, gissara <[hidden email]> ha scritto:
> > Ciao,
> >
> > Grazie mille per l'aiuto. Capisco ciò che intende ma non sono sicura di
> > poter definire dei trigger adeguati per avitare delle conflittualità.
> Per il
> > join spaziale ho usato il campo denominazione dello shape fabbricati, da
> cui
> > mi dovrei estrarre le informazioni geometriche, a questo ho anche
> agganciato
> > le tabelle delle schede descrittive.
>
> In un primo tempo ho inteso "join spaziale" come un collegamento solo
> tramite relazione spaziale: es. un punto che rappresenta la scheda da
> rilievo correlata al fabbricato tramite una funzione ST_Contains().
> Ora mi par di capire che hai una chiave esterna, ovvero un campo della
> scheda descrittiva che fa riferimento allo shape fabbricati.
>
> Non ho capito bene gli strumenti che stai usando: il consiglio è di
> importare tutto in un database, magari Spatialite che è contenuto in
> un unico file, poi potrai visualizzare e gestire tutto agevolmente da
> QGIS; per creare il db sempre meglio la spatialite gui [0]:
>
> Anch'io ci vedo due ordini di problemi:
>  - la definizione di chiavi robuste che non cambino nel tempo (legate
> alla stessa definizione di entità fabbricato)
>  - evitare la moltiplicazione di tabelle
>
> Non so bene la struttura dello shapefile fabbricati ma un campo che si
> chiama "denominazione" non mi ispira dei valori univoci e immutabili
> nel tempo. Se c'è un codice o un numero (magari a partire dalla ctr)
> meglio utilizzare quello o al limite la ID della feature (se hai un
> poligono o multipoligono per ciascun fabbricato)
>
> Per i dati dell'analisi sicuramente conviene creare delle tabella con
> le informazioni ricorrenti da correlare con una relazione molti a
> molti, ad esempio immagino una tabella con la lista degli elementi
> strutturali o architettonici in cui avere un nome breve e una
> descrizione, per evitare di ricopiare mille volte nella tabella schede
> cose tipo "copertura a due falde in legno sostenuta da capriate alla
> lombarda..." Anche le informazioni realative ai materiali e allo stato
> di conservazione le vedrei bene ciascuna su una tabella in maniera
> tale che compilando la scheda non ci siano ripetizioni. Anceh senza
> creare dei trigger, è opportuno che siano definite bene le chiavi
> esterne.. vedi qui [1] e qui [2] alcuni concetti di base se non sei
> già esperta di database.
>
> La maschera di inserimento/visualizzazione può esser un po'
> complicata, e devo ammettere che io non ho mai utilizzato
> il widget "relazione" in QGIS ma dovrei falro presto...
>
> Spero di non aver creato confusione.. facci sapere come procede.
>
> Amedeo Fadini
>
> [0] https://www.gaia-gis.it/fossil/spatialite_gui/index
> [1] https://www.postgresql.org/docs/9.4/static/ddl-constraints.html#DDL-
> CONSTRAINTS-PRIMARY-KEYS
> [2] https://www.gaia-gis.it/gaia-sins/spatialite-cookbook/html/
> create-db.html
> _______________________________________________
> [hidden email]
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 807 iscritti al 31/03/2016

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
807 iscritti al 31/03/2016

[gissara]

CONTENTS DELETED

The author has deleted this message.