[Gfoss] R: postgresql/postgis: due colonne geometry stessa tabella

[a.furieri a lqt.it]

On Thu, 20 Aug 2015 09:00:07 +0200, Andrea Peri wrote:
> Certo e' un vero peccato che qgis continui a disincentivare un uso
> evoluto del dato spaziale e continui a rincorrere arcgis sulla sua
> strada. Dovrebbe invece smarcarsi percorrendo strade nuove. Va notato
> infatti che arcgis con il suo geodatabase non consente di avere piu'
> di 1 geometria su una tabella. QGIS si ma in teoria, perche' in
> pratica ne penalizza l'impiego per cui e' come dire , non usarla.
>

Andrea,

personalmente trovo particolarmente stimolante questa tua osservazione.

a partire quanto meno dall'ultimo quindicennio lo stato dell'arte delle
tecnologie GeoSpatial e' ormai robustamente disciplinato da numerosi
riferimenti concettuali e normativi dettagliatamente descritti e
minuziosamente formalizzati e standardizzati.

ormai siamo fortunamente ben lontani dalle prime avventurose esperienze
"do it yourself" dei tempi eroici, quando ciascun singolo sw 
applicativo
era libero di inventarsi con alterne fortune i propri modelli di
riferimento preferiti, con l'ovvio effetto di creare alla fine un caos
ingovernabile che uccideva qualsiasi interoperabilita'.

anche se il modello standard viene poi declinato in numerose varianti
dialettali (SQL/SFS, SQL/MM, WKT, WKB, GML, GeoJSON etc) e' comunque
assolutamente chiaro che esiste un nucleo centrale immutabile e molto
robustamente radicato che si incardina sulle sette classi canoniche:
POINT, LINESTRING, POLYGON, MULTIPOINT, MULTILINESTRING, MULTIPOLYGON
e GEOMETRYCOLLECTION, con l'aggiunta dell'ottava classe generica
GEOMETRY.

non c'e' assolutamente nulla nel modello standard che proibisca di
gestire in parallelo un numero arbitrario di geometrie per la medesima
feature; gli esempi pratici in cui una capacita' di questa natura
risulta sicuramente utile non mancano certo:
- localita' abitate rappresentate sia come aree poligonali che come
   punti (da utilizzarsi a seconda della scala di rappresentazione)
- confini amministrativi, fiumi, strade, ferrovie, curve di livello
   etc a diversi livelli di risoluzione e dettaglio (anche qua: da
   utilizzarsi in relazione alla scala di rappresentazione)
- rappresentazioni statiche in diversi SRID alternativi in modo
   tale da evitare il perditempo della riproiezione "al volo"
- etc etc etc

inoltre il modello standard consente esplicitemente di utilizzare
le due classi "fritto misto" GEOMETRYCOLLECTION e GEOMETRY; e pure
questa e' un'opzione che puo' risultare decisamente utile in svariati
casi d'uso concreti (se non altro, per potere ispezionare correttamente
i risultati di operazioni spatial quali p.es. ST_Intersection).

Andrea gia' faceva notare come gestire layers che contangano piu'
di una singola colonna Geometry sia materialmente difficoltoso
quando si utilizzano i piu' diffusi applicativi desktop GIS.
di fatto la situazione per GEOMETRYCOLLECTION e GEOMETRY e' ben
peggiore; visualizzare geometrie che appartengano ad una di queste
due classi non e' semplicemente difficoltoso, e' tassativamente
proibito :-D

esistono validi motivi tecnici che giustifichino queste scelte ?
non pare proprio: qualsiasi servizio WebGIS basato su protocolli
standard WMS/WFS riesce tranquillamente a gestire indistintamente
tutte quante le  classi geometriche canoniche senza difficolta',
cosi' come riesce facilmente a pubblicare layers multi-geometria
(magari andandosi a pescare automaticamente il livello di
risoluzione e dettaglio piu' adeguato in base alla scala).

e allora perche' mai non ci riescono i desktop-GIS ?
temo che la risposta piu' adeguata sia quella gia' identificata
da Andrea; perche' piu' o meno tutti i desktop-GIS (sia free
che proprietari) aderiscono sostanzialmente ad un unico modello
concettuale che in ultima analisi e' quello di ArcGis.
piu' che sugli standard piu' recenti questo modello continua
invece ancora oggi a basarsi sostanzialmente sulle limitate e
rigide opzioni supportate dal venerabile (ed obsoleto) Shapefile.
il supporto per strutture dati un po' piu' fresche e meno ammuffite
(SQL, WFS, GML etc) e' indubbiamente presente, ma deve comunque
adattarsi alle "maglie strette" imposte dal precedente modello shp;
tutto quel che eccede i limiti intrinseci di quel vecchio modello
viene sacrificato, oppure costringe a contorsioni avventurose.
ed e' veramente un peccato: servirebbe un po' d'aria fresca. ;-)

ciao Sandro