[Gfoss] tabelle tipizzate in Postgres di schede descrittive

[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" <amefad a gmail.com> ha scritto:

> Ciao Lucia e benvenuta in lista...
>
> Il 18 settembre 2016 19:57, gissara <luciaargento89 a gmail.com> 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
> _______________________________________________
> Gfoss a lists.gfoss.it
> 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