Qgis e recipe #19 di Spatialite cookbook

[Beppe]

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

[a.furieri]

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 ;-)

> 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 :-)

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 ;-)

ciao Sandro
_______________________________________________
[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.
666 iscritti al 22.7.2013

[Andrea Peri]

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, <[hidden email]> 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 ;-)

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 :-)

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 ;-)

ciao Sandro

_______________________________________________
[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.
666 iscritti al 22.7.2013

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

_______________________________________________
[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.
666 iscritti al 22.7.2013

[Beppe]

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

[a.furieri]

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 ;-)

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
_______________________________________________
[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.
666 iscritti al 22.7.2013