Re: [Gfoss] R: [ SARDEGNA ] - Shapefile ed errori (?)

2018-03-22 Per discussione Totò Fiandaca
Faccio notare che le geometrie non valide sugli shapefile messi a
disposizione dall'ISTAT si propagano nel tempo, anche quelle del 2018 hanno
le stesse identiche geometrie non valide, non solo per i comuni, ma anche
per le province e regioni.

ecco un articolo di Furieri che analizza gli shappe del 2011
https://www.gaia-gis.it/fossil/libspatialite/wiki?name=invalid-geometries

l'altro ieri ho scritto una mail all'ISTAT per avvisarli del problema.

saluti

Il giorno 22 marzo 2018 19:49, nino formica  ha
scritto:

> Ciao Sandro,
>
> non ho nulla da aggiungere alla tua risposta, come sempre esauriente.
> Ma mi viene di fare una considerazione più generale.
>
> Noto come spesso ci siamo problemi dovuti al fatto che le persone fanno
> passaggi e ripassaggi da un formato dati a un altro e quasi sempre di mezzo
> ci sono gli shapefile.
>
> Ora, non sarebbe più semplice la vita se, a parte quando necessario, si
> lavorasse sempre con un solo formato, spatialite o un altro che si
> preferisce, evitando di fare continue trasformazioni e soprattutto evitando
> l'uso del vetusto shapefile ?
>
> Scusa la mia riflessione banale !
>
> Saluti
> Nino
>
>
>
> Il gio 22 mar 2018, 16:43  ha scritto:
>
> > ah ah, ancora una volta fanno capolino le mitiche "banane" :-D
> >
> > esiste un caso particolarissimo di "Poligono con buco interno"
> > in cui il software prodotto da ESRI adotta una convenzione che
> > fa a pugni con gli standard dettati da OGC (vedi figura allegata).
> > il problema nasce quando il "buco" tocca direttamente il boundary
> > della figura; capita molto spesso lungo la linea costiera, quando
> > si incontrano piccolissime insenature.
> >
> > - in questo case secondo ESRI e' lecito disegnare il solo
> >Exterior Ring, che dal punto P entra dentro alla figura,
> >descrive il contorno del "buco", e poi riesce fuori passando
> >ancora una volta dal punto P.
> >
> > - ma questo non e' tollerabile secondo le specifiche degli
> >standard OGC, perche' qualsiasi Ring non puo' mi avere
> >dei punti di autotangenze.
> >quindi, secondo OGC, una topologia di questo tipo va
> >obbligatoriamente descritta utilizzando un Exterior
> >Ring ed un Interior Ring (che ovviamente si intersecano
> >sul punto P, ma questo e' legittimo).
> >
> > ho appena controllato su SpatiaLite lo shape ISTAT 2016:
> >
> > SELECT comune
> > FROM com2016_wgs84
> > WHERE cod_reg = 20 AND
> >ST_IsValid(geometry) <> 1;
> > ---
> > La Maddalena
> > Calasetta
> >
> > in Sardegna ci sono due comuni "stile ESRI", e sono
> > proprio loro quelli che disturbano.
> >
> > correggere gli errori fino ad ottenere delle geometrie
> > impeccabili perfettamente coerenti con i requisiti
> > richiesti dagli standard OGC e' decisamente molto
> > semplice:
> >
> > UPDATE com2016_wgs84
> > SET geometry = MakeValid(geometry)
> > WHERE cod_reg = 20
> >AND ST_IsValid(geometry) <> 1;
> >
> > verifica finale:
> >
> > SELECT comune, ST_IsValid(geometry)
> > FROM com2016_wgs84
> > WHERE comune in ('La Maddalena', 'Calasetta');
> > 
> > La Maddalena1
> > Calasetta   1
> >
> > ora finalmente e' tutto a posto ;-)
> >
> > 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.
> > 796 iscritti al 28/12/2017
> ___
> 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.
> 796 iscritti al 28/12/2017
>



-- 
*Ing. Salvatore Fiandaca*
*mobile*.:+39 327.493.8955
*m*: *pigrecoinfin...@gmail.com *
*C.F*.: FNDSVT71E29Z103G
*P.IVA*: 06597870820
*membro QGIS Italia - http://qgis.it/ *
*socio GFOSS.it - *http://gfoss.it/
*blog:*
* https://pigrecoinfinito.wordpress.com/
 FB: Co-admin
- https://www.facebook.com/qgis.it/ **
 *
*FB: moderatore - **https://www.facebook.com/groups/GisItalia/
**
 *
*TW:  **https://twitter.com/totofiandaca
*

43°51'0.54"N  10°34'27.62"E - EPSG:4326

“Se la conoscenza deve essere aperta a tutti,
perchè mai limitarne l’accesso?”
R. Stallman

Questo documento, allegati inclusi, contiene informazioni di proprietà di
FIANDACA SALVATORE e deve essere utilizzato esclusivamente dal destinatario
in relazione alle finalità per le quali è stato ricevuto. E' vietata
qualsiasi forma di riproduzione o divulgazione

Re: [Gfoss] R: [ SARDEGNA ] - Shapefile ed errori (?)

2018-03-22 Per discussione nino formica
Ciao Sandro,

non ho nulla da aggiungere alla tua risposta, come sempre esauriente.
Ma mi viene di fare una considerazione più generale.

Noto come spesso ci siamo problemi dovuti al fatto che le persone fanno
passaggi e ripassaggi da un formato dati a un altro e quasi sempre di mezzo
ci sono gli shapefile.

Ora, non sarebbe più semplice la vita se, a parte quando necessario, si
lavorasse sempre con un solo formato, spatialite o un altro che si
preferisce, evitando di fare continue trasformazioni e soprattutto evitando
l'uso del vetusto shapefile ?

Scusa la mia riflessione banale !

Saluti
Nino



Il gio 22 mar 2018, 16:43  ha scritto:

> ah ah, ancora una volta fanno capolino le mitiche "banane" :-D
>
> esiste un caso particolarissimo di "Poligono con buco interno"
> in cui il software prodotto da ESRI adotta una convenzione che
> fa a pugni con gli standard dettati da OGC (vedi figura allegata).
> il problema nasce quando il "buco" tocca direttamente il boundary
> della figura; capita molto spesso lungo la linea costiera, quando
> si incontrano piccolissime insenature.
>
> - in questo case secondo ESRI e' lecito disegnare il solo
>Exterior Ring, che dal punto P entra dentro alla figura,
>descrive il contorno del "buco", e poi riesce fuori passando
>ancora una volta dal punto P.
>
> - ma questo non e' tollerabile secondo le specifiche degli
>standard OGC, perche' qualsiasi Ring non puo' mi avere
>dei punti di autotangenze.
>quindi, secondo OGC, una topologia di questo tipo va
>obbligatoriamente descritta utilizzando un Exterior
>Ring ed un Interior Ring (che ovviamente si intersecano
>sul punto P, ma questo e' legittimo).
>
> ho appena controllato su SpatiaLite lo shape ISTAT 2016:
>
> SELECT comune
> FROM com2016_wgs84
> WHERE cod_reg = 20 AND
>ST_IsValid(geometry) <> 1;
> ---
> La Maddalena
> Calasetta
>
> in Sardegna ci sono due comuni "stile ESRI", e sono
> proprio loro quelli che disturbano.
>
> correggere gli errori fino ad ottenere delle geometrie
> impeccabili perfettamente coerenti con i requisiti
> richiesti dagli standard OGC e' decisamente molto
> semplice:
>
> UPDATE com2016_wgs84
> SET geometry = MakeValid(geometry)
> WHERE cod_reg = 20
>AND ST_IsValid(geometry) <> 1;
>
> verifica finale:
>
> SELECT comune, ST_IsValid(geometry)
> FROM com2016_wgs84
> WHERE comune in ('La Maddalena', 'Calasetta');
> 
> La Maddalena1
> Calasetta   1
>
> ora finalmente e' tutto a posto ;-)
>
> 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.
> 796 iscritti al 28/12/2017
___
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.
796 iscritti al 28/12/2017

Re: [Gfoss] R: [ SARDEGNA ] - Shapefile ed errori (?)

2018-03-22 Per discussione a . furieri

On Thu, 22 Mar 2018 16:43:22 +0100, a.furi...@lqt.it wrote:

ah ah, ancora una volta fanno capolino le mitiche "banane" :-D

esiste un caso particolarissimo di "Poligono con buco interno"
in cui il software prodotto da ESRI adotta una convenzione che
fa a pugni con gli standard dettati da OGC (vedi figura allegata).
il problema nasce quando il "buco" tocca direttamente il boundary
della figura; capita molto spesso lungo la linea costiera, quando
si incontrano piccolissime insenature.



noto che ora il mail server di Gfoss.it non consente piu' di
allegare neppure un microscopico PNG da 4 KB :-P

ad ogni buon conto, chi e' interessato alla figura citata
come esempio la puo' trovare qua:

http://www.gaia-gis.it/buchi.png

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.
796 iscritti al 28/12/2017

Re: [Gfoss] R: [ SARDEGNA ] - Shapefile ed errori (?)

2018-03-22 Per discussione a . furieri

ah ah, ancora una volta fanno capolino le mitiche "banane" :-D

esiste un caso particolarissimo di "Poligono con buco interno"
in cui il software prodotto da ESRI adotta una convenzione che
fa a pugni con gli standard dettati da OGC (vedi figura allegata).
il problema nasce quando il "buco" tocca direttamente il boundary
della figura; capita molto spesso lungo la linea costiera, quando
si incontrano piccolissime insenature.

- in questo case secondo ESRI e' lecito disegnare il solo
  Exterior Ring, che dal punto P entra dentro alla figura,
  descrive il contorno del "buco", e poi riesce fuori passando
  ancora una volta dal punto P.

- ma questo non e' tollerabile secondo le specifiche degli
  standard OGC, perche' qualsiasi Ring non puo' mi avere
  dei punti di autotangenze.
  quindi, secondo OGC, una topologia di questo tipo va
  obbligatoriamente descritta utilizzando un Exterior
  Ring ed un Interior Ring (che ovviamente si intersecano
  sul punto P, ma questo e' legittimo).

ho appena controllato su SpatiaLite lo shape ISTAT 2016:

SELECT comune
FROM com2016_wgs84
WHERE cod_reg = 20 AND
  ST_IsValid(geometry) <> 1;
---
La Maddalena
Calasetta

in Sardegna ci sono due comuni "stile ESRI", e sono
proprio loro quelli che disturbano.

correggere gli errori fino ad ottenere delle geometrie
impeccabili perfettamente coerenti con i requisiti
richiesti dagli standard OGC e' decisamente molto
semplice:

UPDATE com2016_wgs84
SET geometry = MakeValid(geometry)
WHERE cod_reg = 20
  AND ST_IsValid(geometry) <> 1;

verifica finale:

SELECT comune, ST_IsValid(geometry)
FROM com2016_wgs84
WHERE comune in ('La Maddalena', 'Calasetta');

La Maddalena1
Calasetta   1

ora finalmente e' tutto a posto ;-)

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.
796 iscritti al 28/12/2017