Ciao a Tutti,
premessa: per attività varie avremmo bisogno di un DEM / DTM della Regione Sardegna (RS) (mi pare che il Geoportale Regionale NON lo fornisca in un unico "file"). Per questo, abbiamo scaricato un DEM a 20 metri da ISPRA: http://www.sinanet.isprambiente.it/it/sia-ispra/download-mais/dem20/at_download/file e, da ISTAT, i limiti amministrativi italiani, versione non generalizzata: http://www.istat.it/storage/cartografia/confini_amministrativi/archivio-confini/non_generalizzati/2016/Limiti_2016_WGS84.zip In seguito abbiamo Cercato di "ritagliare" il DEM nazionale con la sola RS ma la procedura non viene completata per un "errore" legato alle geometrie. Da "Strumenti di geometria", "Controllo di validità" abbiamo effettuatoun check che hanno restituito diverse problematiche sullo shapefile ISTAT sulla Regione Puglia ma nessuna anomalia su RS. Ri-esegeuendo il "ritaglia" DEM con RS vector compare ancora un Warning: Warning 1: Ring Self-intersection at or near point 444979.67760000005 4320623.5316000003 ERROR 1: Cutline polygon is invalid. errore peraltro NON rilevato da "Strumenti di geometria", "Controllo di validità"... Mi fa "strano" che: - siano presenti "errori" su dati "ufficiali" (o che vengano rilevati come tali, o meno, a seconda dello strumento utilizzato) - che il "controlla validità" non rilevi problemi sullo shapefile di RS mentre il tool "ritaglia con maschera" ne trovi uno (444979.67760000005 4320623.5316000003). - che il "v.build.check" non rilevi problemi Non sono riuscito a risolvere... Evidentemente sbaglio qualcosa e/o non so come gestire al meglio la problematica. Qualche idea? Grazie. Ciao, Francesco. _______________________________________________ [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. 796 iscritti al 28/12/2017 |
Ciao Francesco,
secondo me per ritagliare il DTM non hai bisogno dello shapefile con i confini della Sardegna. Infatti essendo un isola, di per sè il DTM viene delimitato dalla linea costiera. Perciò ti basta clippare con un poligono fatto a mano che più o meno racchiude la Sardegna. Saluti Nino Il gio 22 mar 2018, 14:24 [hidden email] [via Gfoss -- Geographic Free and Open Source Software - Italian mailing list] < [hidden email]> ha scritto: > Ciao a Tutti, > > premessa: per attività varie avremmo bisogno di un DEM / DTM della Regione > Sardegna (RS) (mi pare che il Geoportale Regionale NON lo fornisca in un > unico "file"). > > Per questo, abbiamo scaricato un DEM a 20 metri da ISPRA: > http://www.sinanet.isprambiente.it/it/sia-ispra/download-mais/dem20/at_download/file > > e, da ISTAT, i limiti amministrativi italiani, versione non generalizzata: > http://www.istat.it/storage/cartografia/confini_amministrativi/archivio-confini/non_generalizzati/2016/Limiti_2016_WGS84.zip > > In seguito abbiamo Cercato di "ritagliare" il DEM nazionale con la sola RS > ma la procedura non viene completata per un "errore" legato alle geometrie. > > Da "Strumenti di geometria", "Controllo di validità" abbiamo effettuatoun > check che hanno restituito diverse problematiche sullo shapefile ISTAT > sulla Regione Puglia ma nessuna anomalia su RS. > > Ri-esegeuendo il "ritaglia" DEM con RS vector compare ancora un Warning: > > Warning 1: Ring Self-intersection at or near point 444979.67760000005 > 4320623.5316000003 > ERROR 1: Cutline polygon is invalid. > > errore peraltro NON rilevato da "Strumenti di geometria", "Controllo di > validità"... > > Mi fa "strano" che: > > - siano presenti "errori" su dati "ufficiali" (o che vengano rilevati come > tali, o meno, a seconda dello strumento utilizzato) > - che il "controlla validità" non rilevi problemi sullo shapefile di RS > mentre il tool "ritaglia con maschera" ne trovi uno (444979.67760000005 > 4320623.5316000003). > - che il "v.build.check" non rilevi problemi > > Non sono riuscito a risolvere... > > Evidentemente sbaglio qualcosa e/o non so come gestire al meglio la > problematica. Qualche idea? > > Grazie. > > Ciao, > Francesco. > > > _______________________________________________ > [hidden email] <http:///user/SendEmail.jtp?type=node&node=7597799&i=0> > 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 > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/SARDEGNA-Shapefile-ed-errori-tp7597799.html > To unsubscribe from Gfoss -- Geographic Free and Open Source Software - > Italian mailing list, click here > < > . > NAML > <http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > [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. 796 iscritti al 28/12/2017 |
In reply to this post by francesco.fiermonte@polito.it
Buongiorno a tutti
In questi giorni ho rielaborato delle aree, che avevo generato tempo addietro con Qgis 2.18, utilizzando prima la 3.0 e successivamente la 3.1.0-19 e nel "raggruppare" più shape in un unico file ho iniziato ad avere errori sulle geometrie e sull'Extent Ho importato i vari shape file in Spatialite nessun errore, eseguiti i vari check sulle geometrie nessuna segnalazione. Riesportati i vari shapefile da Spatialite provo un banale copia e incolla tra due shapefile omogenei Polygon (WKB type: "Polygon") stessi errori sulle geometrie Riprendo in mano il lavoro con Qgis 2.18.17-1 tutto ok nessun problema Ora non escludo un mio uso errato di Qgis o di aver commesso qualche errore ma non ho trovato spiegazione agli errori riscontrati con l'utilizzo di Qgis 3.0 e 3.1 durante l'elaborazione di shapefile Polygon Suggerimenti? Grazie Buona serata Stefano Alibrandi =================================================================== ACQUE VERONESI S.C. a R.L. Sistemi Informativi Territoriali e Modellazione [hidden email] tel. 045 8677814 =================================================================== -----Messaggio originale----- Da: Gfoss [mailto:[hidden email]] Per conto di [hidden email] Inviato: giovedì 22 marzo 2018 14:24 A: GFOSS.it Oggetto: [Gfoss] [ SARDEGNA ] - Shapefile ed errori (?) Ciao a Tutti, premessa: per attività varie avremmo bisogno di un DEM / DTM della Regione Sardegna (RS) (mi pare che il Geoportale Regionale NON lo fornisca in un unico "file"). Per questo, abbiamo scaricato un DEM a 20 metri da ISPRA: http://www.sinanet.isprambiente.it/it/sia-ispra/download-mais/dem20/at_download/file e, da ISTAT, i limiti amministrativi italiani, versione non generalizzata: http://www.istat.it/storage/cartografia/confini_amministrativi/archivio-confini/non_generalizzati/2016/Limiti_2016_WGS84.zip In seguito abbiamo Cercato di "ritagliare" il DEM nazionale con la sola RS ma la procedura non viene completata per un "errore" legato alle geometrie. Da "Strumenti di geometria", "Controllo di validità" abbiamo effettuatoun check che hanno restituito diverse problematiche sullo shapefile ISTAT sulla Regione Puglia ma nessuna anomalia su RS. Ri-esegeuendo il "ritaglia" DEM con RS vector compare ancora un Warning: Warning 1: Ring Self-intersection at or near point 444979.67760000005 4320623.5316000003 ERROR 1: Cutline polygon is invalid. errore peraltro NON rilevato da "Strumenti di geometria", "Controllo di validità"... Mi fa "strano" che: - siano presenti "errori" su dati "ufficiali" (o che vengano rilevati come tali, o meno, a seconda dello strumento utilizzato) - che il "controlla validità" non rilevi problemi sullo shapefile di RS mentre il tool "ritaglia con maschera" ne trovi uno (444979.67760000005 4320623.5316000003). - che il "v.build.check" non rilevi problemi Non sono riuscito a risolvere... Evidentemente sbaglio qualcosa e/o non so come gestire al meglio la problematica. Qualche idea? Grazie. Ciao, Francesco. _______________________________________________ [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. 796 iscritti al 28/12/2017 _______________________________________________ [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. 796 iscritti al 28/12/2017 |
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 Maddalena 1 Calasetta 1 ora finalmente e' tutto a posto ;-) 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. 796 iscritti al 28/12/2017 |
On Thu, 22 Mar 2018 16:43:22 +0100, [hidden email] 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 _______________________________________________ [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. 796 iscritti al 28/12/2017 |
In reply to this post by a.furieri
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 <[hidden email]> 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 Maddalena 1 > Calasetta 1 > > ora finalmente e' tutto a posto ;-) > > 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. > 796 iscritti al 28/12/2017 [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. 796 iscritti al 28/12/2017 |
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 <[hidden email]> 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 <[hidden email]> 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 Maddalena 1 > > Calasetta 1 > > > > ora finalmente e' tutto a posto ;-) > > > > 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. > > 796 iscritti al 28/12/2017 > _______________________________________________ > [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. > 796 iscritti al 28/12/2017 > -- *Ing. Salvatore Fiandaca* *mobile*.:+39 327.493.8955 *m*: *[hidden email] <[hidden email]>* *C.F*.: FNDSVT71E29Z103G *P.IVA*: 06597870820 *membro QGIS Italia - http://qgis.it/ <http://qgis.it/>* *socio GFOSS.it - *http://gfoss.it/ *blog:* * https://pigrecoinfinito.wordpress.com/ <https://pigrecoinfinito.wordpress.com/> FB: Co-admin - https://www.facebook.com/qgis.it/ <https://www.facebook.com/qgis.it/>** <https://www.facebook.com/qgis.it/> * *FB: moderatore - **https://www.facebook.com/groups/GisItalia/ <https://www.facebook.com/groups/GisItalia/>** <https://www.facebook.com/groups/GisItalia/> * *TW: <http://goog_95411464>**https://twitter.com/totofiandaca <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 senza l'esplicito consenso di FIANDACA SALVATORE. Qualora fosse stato ricevuto per errore si prega di informare tempestivamente il mittente e distruggere la copia in proprio possesso. _______________________________________________ [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. 796 iscritti al 28/12/2017 |
Free forum by Nabble | Edit this page |