[Gfoss] Qgis e recipe #19 di Spatialite cookbook

Local Chapters GFOSS.it
1

Salve a tutti!
Nella ricetta #19 dello Spatialite Cookbook mi sono reso conto che il file
che dovrebbe contenere il merging dei comuni a formare le provincie non
viene aperto da QGIS, o meglio viene visto come "tabella senza geometria".
Ciò non ostante, se controllo da SpatialiteGUI le geometrie sono
visualizzabili correttamente sia mediante il menù Map Preview che con
comando del menù contestuale "Blob Explore".

Ho seguito la seguente procedura indicata dallo Spatialite Cookbook:

1-Creato un nuovo db (srid 23032, codifica cp152) nel quale ho importato lo
shapefile com2010_g (SRID 23032, codifica CP152, lasciando deselezionate le
opzioni della voce "Geometry Storage", selezionando alla voce "Geometry
Type" l'opzione "Mode:Automatic" ed alla voce "Primary Key Column" l'opzione
"Automatic".

2-Ho creato la view 'local_councils':
  CREATE VIEW local_councils AS
  SELECT c.cod_reg AS cod_reg,
    c.cod_pro AS cod_pro,
    c.cod_com AS cod_com,
    c.nome_com AS nome_com,
    p.nome_pro AS nome_pro,
    p.sigla AS sigla,
    r.nome_reg AS nome_reg,
    c.geometry AS geometry
  FROM com2010_g AS c
  JOIN prov2010_g AS p USING (cod_pro)
  JOIN reg2010_g AS r USING(cod_reg)

3-Ho creato la tabella 'counties' e relativa colonna geometrica:
  CREATE TABLE counties AS
  SELECT cod_pro, nome_pro, sigla, cod_reg, nome_reg,
    ST_Union(geometry) AS geometry
  FROM local_councils
  GROUP BY cod_pro
  
  SELECT RecoverGeometryColumn('counties', 'geometry',
    23032, 'MULTIPOLYGON', 'XY').

Ho copiato e incollato i comandi dal Cookbook su SpatialiteGUI per evitare
errori di digitazione, sto sbagliando qualcosa?

Grazie in anticipo
Beppe

--
View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Qgis-e-recipe-19-di-Spatialite-cookbook-tp7587047.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.

2

Ciao Beppe,

come diceva Mao Tse Tung:
"quando trovi uno che ha fame non gli regalare mai un pesce;
  insegnagli piuttosto ad usare la canna da pesca"

vedi i miei commenti passo per passo:

On Wed, 5 Mar 2014 10:09:52 -0800 (PST), Beppe wrote:

Salve a tutti!
Nella ricetta #19 dello Spatialite Cookbook mi sono reso conto che il file

giusto per pedante precisione: non e' affatto un "file", e' una tavola
dentro ad un DB-file ... tutt'altra zuppa :wink:

che dovrebbe contenere il merging dei comuni a formare le provincie non
viene aperto da QGIS, o meglio viene visto come "tabella senza geometria".
Ciò non ostante, se controllo da SpatialiteGUI le geometrie sono
visualizzabili correttamente sia mediante il menù Map Preview che con
comando del menù contestuale "Blob Explore".

Ho seguito la seguente procedura indicata dallo Spatialite Cookbook:

1-Creato un nuovo db (srid 23032, codifica cp152) nel quale ho importato lo
shapefile com2010_g (SRID 23032, codifica CP152, lasciando deselezionate le
opzioni della voce "Geometry Storage", selezionando alla voce "Geometry
Type" l'opzione "Mode:Automatic" ed alla voce "Primary Key Column" l'opzione
"Automatic".

2-Ho creato la view 'local_councils':
  CREATE VIEW local_councils AS
  SELECT c.cod_reg AS cod_reg,
    c.cod_pro AS cod_pro,
    c.cod_com AS cod_com,
    c.nome_com AS nome_com,
    p.nome_pro AS nome_pro,
    p.sigla AS sigla,
    r.nome_reg AS nome_reg,
    c.geometry AS geometry
  FROM com2010_g AS c
  JOIN prov2010_g AS p USING (cod_pro)
  JOIN reg2010_g AS r USING(cod_reg)

3-Ho creato la tabella 'counties' e relativa colonna geometrica:
  CREATE TABLE counties AS
  SELECT cod_pro, nome_pro, sigla, cod_reg, nome_reg,
    ST_Union(geometry) AS geometry
  FROM local_councils
  GROUP BY cod_pro

  SELECT RecoverGeometryColumn('counties', 'geometry',
    23032, 'MULTIPOLYGON', 'XY').

e qua ti sei evidentemente distratto :slight_smile:

quest'ultima SELECT ritorna ZERO ... cioe' FALSE
insomma, non e' andata a buon fine, non ce l'ha fatta proprio a ricoverare
correttamente la geometria.
conclusione: non hai affatto una tavola Spatial, hai ancora una banale
tavola di tipo ordinario (anche se contiene delle geometrie) perche'
non e' registrata su "geometry_columns"
e di conseguenza QGIS ti dice (correttamente) che non trova nessuna
tavola Spatial (aka layer) che si chiami "counties".

andiamo a verificare perche' la RecoverGeometryColumn fallisce:

SELECT Count(*) AS count, ST_GeometryType(geometry) AS type,
   ST_SRID(geometry) AS srid, CoordDimension(geometry) AS dims
FROM counties
GROUP BY type, srid;
-------
44 MULTIPOLYGON 23032 XY
66 POLYGON 23032 XY

ora e' tutto chiaro; la tavola "counties" contiene geometrie
di tipo misto: qualche volta poligoni semplici, altre volte
poligoni multipli (pensa p.es. a tutte le provincie sulla
costa che hanno isole, isolotti, scogli etc).

nelle versioni piu' recenti di splite i controlli di tipo
sono rigidamente inflessibili; non puoi registrare una "vera
e genuina" tavola Spatial se il tipo geometrico non e'
rigorosamente univoco.

soluzione A)
------------
UPDATE counties SET geometry = CastToMultiPolygon(geometry);

cioe' applichiamo a posteriori un casting sul tipo geometrico;
questa UPDATE assicura che tutto verra' convertito a MultiPolygon
in modo rigorosamente consistente.

soluzione B)
------------
correggiamo la SELECT di origine in modo tale da renderla
aderente ai requisiti delle ultime versioni (personalmente,
preferisco questa seconda soluzione):

DROP TABLE counties;

CREATE TABLE counties AS
SELECT cod_pro, nome_pro, sigla, cod_reg, nome_reg,
   CastToMultiPolygon(ST_Union(geometry)) AS geometry
FROM local_councils
GROUP BY cod_pro;

SELECT RecoverGeometryColumn('counties', 'geometry',
   23032, 'MULTIPOLYGON', 'XY');

voila: ora finalmente funziona tutto correttamente :wink:

ciao Sandro

3

Una precisazione.

Secondo me sarebbe piu’ indicato usare il costrutto

ST_Multi()
al posto del costrutto CastoToMulti().

Su spatialite ST_Multi() è un alias di CastToMulti() e quindi usare luno o l’altro è indifferente.
Ma ST_Multi() è usato anche da Postgis e proviene da ISO per cui a parer mio ha un valore simbolico superiore.

O esiste una differenza che ignoro tra CastToMulti() e ST_Multi()
?

···

Il giorno 05 marzo 2014 19:59, <a.furieri@lqt.it> ha scritto:

Ciao Beppe,

come diceva Mao Tse Tung:
“quando trovi uno che ha fame non gli regalare mai un pesce;
insegnagli piuttosto ad usare la canna da pesca”

vedi i miei commenti passo per passo:

On Wed, 5 Mar 2014 10:09:52 -0800 (PST), Beppe wrote:

Salve a tutti!
Nella ricetta #19 dello Spatialite Cookbook mi sono reso conto che il file

giusto per pedante precisione: non e’ affatto un “file”, e’ una tavola
dentro ad un DB-file … tutt’altra zuppa :wink:

che dovrebbe contenere il merging dei comuni a formare le provincie non
viene aperto da QGIS, o meglio viene visto come “tabella senza geometria”.
Ciò non ostante, se controllo da SpatialiteGUI le geometrie sono
visualizzabili correttamente sia mediante il menù Map Preview che con
comando del menù contestuale “Blob Explore”.

Ho seguito la seguente procedura indicata dallo Spatialite Cookbook:

1-Creato un nuovo db (srid 23032, codifica cp152) nel quale ho importato lo
shapefile com2010_g (SRID 23032, codifica CP152, lasciando deselezionate le
opzioni della voce “Geometry Storage”, selezionando alla voce “Geometry
Type” l’opzione “Mode:Automatic” ed alla voce “Primary Key Column” l’opzione
“Automatic”.

2-Ho creato la view ‘local_councils’:
CREATE VIEW local_councils AS
SELECT c.cod_reg AS cod_reg,
c.cod_pro AS cod_pro,
c.cod_com AS cod_com,
c.nome_com AS nome_com,
p.nome_pro AS nome_pro,
p.sigla AS sigla,
r.nome_reg AS nome_reg,
c.geometry AS geometry
FROM com2010_g AS c
JOIN prov2010_g AS p USING (cod_pro)
JOIN reg2010_g AS r USING(cod_reg)

3-Ho creato la tabella ‘counties’ e relativa colonna geometrica:
CREATE TABLE counties AS
SELECT cod_pro, nome_pro, sigla, cod_reg, nome_reg,
ST_Union(geometry) AS geometry
FROM local_councils
GROUP BY cod_pro

SELECT RecoverGeometryColumn(‘counties’, ‘geometry’,
23032, ‘MULTIPOLYGON’, ‘XY’).

e qua ti sei evidentemente distratto :slight_smile:

quest’ultima SELECT ritorna ZERO … cioe’ FALSE
insomma, non e’ andata a buon fine, non ce l’ha fatta proprio a ricoverare
correttamente la geometria.
conclusione: non hai affatto una tavola Spatial, hai ancora una banale
tavola di tipo ordinario (anche se contiene delle geometrie) perche’
non e’ registrata su “geometry_columns”
e di conseguenza QGIS ti dice (correttamente) che non trova nessuna
tavola Spatial (aka layer) che si chiami “counties”.

andiamo a verificare perche’ la RecoverGeometryColumn fallisce:

SELECT Count(*) AS count, ST_GeometryType(geometry) AS type,
ST_SRID(geometry) AS srid, CoordDimension(geometry) AS dims
FROM counties
GROUP BY type, srid;

44 MULTIPOLYGON 23032 XY
66 POLYGON 23032 XY

ora e’ tutto chiaro; la tavola “counties” contiene geometrie
di tipo misto: qualche volta poligoni semplici, altre volte
poligoni multipli (pensa p.es. a tutte le provincie sulla
costa che hanno isole, isolotti, scogli etc).

nelle versioni piu’ recenti di splite i controlli di tipo
sono rigidamente inflessibili; non puoi registrare una “vera
e genuina” tavola Spatial se il tipo geometrico non e’
rigorosamente univoco.

soluzione A)

UPDATE counties SET geometry = CastToMultiPolygon(geometry);

cioe’ applichiamo a posteriori un casting sul tipo geometrico;
questa UPDATE assicura che tutto verra’ convertito a MultiPolygon
in modo rigorosamente consistente.

soluzione B)

correggiamo la SELECT di origine in modo tale da renderla
aderente ai requisiti delle ultime versioni (personalmente,
preferisco questa seconda soluzione):

DROP TABLE counties;

CREATE TABLE counties AS
SELECT cod_pro, nome_pro, sigla, cod_reg, nome_reg,

CastToMultiPolygon(ST_Union(geometry)) AS geometry

FROM local_councils
GROUP BY cod_pro;

SELECT RecoverGeometryColumn(‘counties’, ‘geometry’,

23032, ‘MULTIPOLYGON’, ‘XY’);

voila: ora finalmente funziona tutto correttamente :wink:

ciao Sandro

Gfoss@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.
666 iscritti al 22.7.2013

–

Andrea Peri
. . . . . . . . .
qwerty àèìòù

4

Ovviamente avrò ancora tanto da imparare anche quando finirò il Cookbook, che
comunque si prospetta mi darà un'ottima canna da pesca che mi consentirà di
ambire a prede molto sostaziose.
Avevo intuito, dall'esame della table che il problema fosse proprio dovuto
al fatto che le geometrie geometrie sono parte "polygon" e parte
"multipolygon" ma non avevo idea di come poter gestire la "faccenda"...

Grazie di nuovo per il sempre pronto ed esaustivo aiuto e complimenti per
l'efficace citazione di Mao!

Beppe

--
View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Qgis-e-recipe-19-di-Spatialite-cookbook-tp7587047p7587049.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.

5

On Wed, 5 Mar 2014 20:10:28 +0100, Andrea Peri wrote:

Una precisazione.

Secondo me sarebbe piu' indicato usare il costrutto

ST_Multi()
al posto del costrutto CastoToMulti().

Su spatialite ST_Multi() è un alias di CastToMulti() e quindi usare
luno o l'altro è indifferente.
Ma ST_Multi() è usato anche da Postgis e proviene da ISO per cui a
parer mio ha un valore simbolico superiore.

O esiste una differenza che ignoro tra CastToMulti() e ST_Multi()
?

Andrea,

lo standard OCG-SFS non prevede nulla del genere; non sono sicurissimo
al 100% per quanto riguarda ISO SQL/MM, ma non credo che neppure questo
standard piu' recente preveda una specifica formale per gli operatori
di casting.

a ulteriore conferma che ST_Multi() non e' un operatore standard: basta
fare una veloce ricerca su Google per "ST_Multi + Oracle".
non solo emerge chiaramente che tutte le voci che trova sono relative
solamente a PostGIS, ma addirittura esce fuori in prima posizione un post
su GISStackExchange che spiega chiaramente come Oracle Spatial richieda
tutt'altro tipo di approccio per applicare una conversione del tipo
geometrico.
e pure un'analoga ricerca per "ST_Multi + SQL Server" trova un ulteriore
post su GISStackExchange da cui si desume che SQL Server applica un
approccio ancora diverso ... insomma, siamo decisamente in una di
quelle "aree grige" in cui gli standard diventano assai fumosetti,
e quindi di conseguenza ciascuna singola implementazione si arrangia
come meglio crede facendo ricorso alla fantasia :wink:

tutta la famiglia CastToMulti() e' un'estensione fuori standard introdotta
autonomamente da splite: CastToMulti() e' la versione piu' generica
(converte qualsiasi cosa nel suo equivalente MULTI); CastToMultiPolygon(),
CastToMultiLinestring() e CastToMultiPoint() sono sottoversioni piu'
specifiche.

quando poi a posteriori e' emerso che anche PostGIS aveva gia'
implementato una sua estesione altrettanto fuori standard di nome
ST_Multi() che faceva sostanzialmente la stessa cosa, a quel punto
molto semplicemente e' stato aggiunto anche ST_Multi() come ulteriore
alias name proprio per favorire una migliore inter-operabilita' nei
confronti di PostGIS.

alla fine invocare CastToMulti() o ST_Multi() e' esattamente la solita
zuppa; comunque verra' eseguita sempre esattamente la medesima porzione
di codice in entrambi i casi.

ciao Sandro