aree sovrapposte in shape file solo per alcuni software

[Stefano Romanelli]

Buongiorno a tutti,

ho il seguente problema con una serie di shape file relativi all'uso suolo
dell'Honduras ad es [0]:

in pratica GDAL (OGRINFO), QGIS e GRASS GIS identificano una serie di aree
sovrapposte (aree molto grosse, non piccole sovrapposizioni), mentre
SPATIALITE, POSTGIS, ARCVIEW 3.2 e ARCMAP non le identificano e le aree
interrogate (doppie per i software prima citati) forniscono le risposte
giuste sulla classe di uso suolo.

I files sono multipart, lo SRID è 32616

Sembrerebbe qualcosa di simile a quanto riportato tempo fa da Andrea Peri
sui flag che identificavano i record eliminati, ma il problema questa volta
sembra inverso

0) ogrinfo [1]
versione GDAL 2.2.1 su ubuntu

1) QGIS
versione 2.18.14 con gdal 2.2.1 su ubuntu
versione 2.18.11 con gdal 2.2.1 su windows

2) GRASS GIS
versione 7.2.2 con gdal 2.2.2 su ubuntu

3) Postgis lo importa senza aree sovrapposte
versione 2.2 su debian
versione 2.3 su ubuntu

4) Saptialite lo importa senza aree sovrapposte [2]
versione 4.3.0a su ubuntu

5) ArcMap lo apre senza aree sovrapposte
versione 10.0

6) arcview lo apre senza aree sovrapposte
versione 3.2

--------------------------------------------------------------------------------

[0] http://www.atlasmunicipal.org/sites/default/files/0601%20Base%20SIG.zip
lo shape è sotto 0601 Base SIG/2000 Fisiografía y Recursos Naturales/2400
Cobertura y Uso de la Tierra/0601_Cobertura_Choluteca.shp

--------------------------------------------------------------------------------

[1] es. ogrinfo

ogrinfo -sql 'SELECT "CLASS_NAME" FROM "0601_Cobertura_Choluteca" AS c,
(SELECT MakePoint(468172,1452714, 32616) AS geom) AS a WHERE
St_Intersects(c.geometry, a.geom)' -dialect "SQLITE"
0601_Cobertura_Choluteca.shp

INFO: Open of `0601_Cobertura_Choluteca.shp'
      using driver `ESRI Shapefile' successful.

Layer name: SELECT
Geometry: None
Feature Count: 2
Layer SRS WKT:
(unknown)
CLASS_NAME: String (0.0)
OGRFeature(SELECT):0
  CLASS_NAME (String) = Área Húmeda Continental

OGRFeature(SELECT):1
  CLASS_NAME (String) = Camaroneras/salineras

--------------------------------------------------------------------------------

[2] es. spatialite

spatialite> SELECT "CLASS_NAME" FROM choluteca AS c, (SELECT
MakePoint(468172,1452714, 32616) AS geom) AS a WHERE St_Intersects(c.geom,
a.geom);

Camaroneras/salineras
_______________________________________________
[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.
801 iscritti al 19/07/2017

[a.furieri]

On Thu, 7 Dec 2017 12:28:16 +0100, Stefano Romanelli wrote:

> Buongiorno a tutti,
>
> ho il seguente problema con una serie di shape file relativi all'uso
> suolo
> dell'Honduras ad es [0]:
>
> in pratica GDAL (OGRINFO), QGIS e GRASS GIS identificano una serie di
> aree
> sovrapposte (aree molto grosse, non piccole sovrapposizioni), mentre
> SPATIALITE, POSTGIS, ARCVIEW 3.2 e ARCMAP non le identificano e le
> aree
> interrogate (doppie per i software prima citati) forniscono le
> risposte
> giuste sulla classe di uso suolo.
>

Ciao Stefano,

nessuno dei sw da te citati e' in grado di calcolarsi autonomamente le
operazioni geometriche (come p.es. le intersezioni/sovrapposizioni
etc);
tutti quanti (almeno quelli FLOSS/GFOSS) delegano questi lavori alla
libreria GEOS; non ho idea di cosa usino ArcView ed ArcMap, suppongo
roba loro proprietaria.

il problema e' che la GEOS e' disponibile in tante versioni successive,
che a volte possono fornire risultati differenti (p.es. perche' si e'
scoperto in seguito che c'era qualche bacarozzolo che e' poi stato
eliminato  e risolto nelle versioni successive).

vedo che tu riporti le versioni per svariati pacchetti, ma quello
che sarebbe realmente significativo sarebbe andare a vedere quale
versione della GEOS viene realmente utilizzata caso per caso.

nota: molto spesso questi "risultati strani" sono causati da
geometrie sporche che possono trarre in inganno gli algoritmi
di calcolo delle relazioni spaziali.
ti suggerirei di verificare questo aspetto, p.es. utilizzando
la funzione ST_IsValid disponibile sia sotto PostGIS che
sotto SpatiaLite.
nel caso in cui effettivamente nei tuoi datasets ci fossero
delle geometrie invalide dovresti riuscire a correggerle
automaticamente usando la ST_MakeValid (anche questa supportata
tanto da PostGIS come da SpatiaLite).

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.
801 iscritti al 19/07/2017

[Stefano Romanelli]

Ciao Sandro,
grazie per la celere risposta.

ecco quello che sono riuscito a trovare per le versioni di GEOS sotto ubuntu

spatialite GEOS version ........: 3.5.1-CAPI-1.9.1 r4246
qgis Esecuzione con GEOS 3.5.1-CAPI-1.9.1 r4246
postgis_full_version GEOS="3.5.1-CAPI-1.9.1 r4246"
grass GEOS: 3.5.1

Ho importato nuovamente dentro postgres lo shape file, questa volta con
ogr2ogr e ho controllato che nel punto geografico usato nella query
precedente ci fossero due aree sovrapposte, cosa che si è effettivamente
realizzaata

SELECT class_name FROM "0601_cobertura_choluteca" AS c, (SELECT
St_SetSRID(St_MakePoint(468172,1452714), 32616) AS geom) AS a WHERE
St_Intersects(c.wkb_geometry, a.geom);

       class_name
-------------------------
 Área Húmeda Continental
 Camaroneras/salineras
(2 rows)


Quindi ho controllato la validità delle geometrie, sia nel caso della
tabella senza sovrapposizioni importata con shp2pgsql (choluteca1), sia
quella importata con ogr2ogr ("0601_cobertura_choluteca").
Ci sono in entrambi i casi dei problemi simili ad eccezione di due punti
indicati da <--####
Ovviamente senza l'ausilio dei db i file sarebbero inutilizzabili
(importando lo shape in grass individua 2346 aree sovrapposte per un totale
di circa 44 km2 di sovrapposizioni)


SELECT reason(ST_IsValidDetail(geom)),
ST_AsText(location(ST_IsValidDetail(geom))) as location FROM choluteca1
WHERE St_IsValid(geom)=false ORDER BY 1,2;

         reason         |               location
------------------------+--------------------------------------
 Ring Self-intersection | POINT(464742.558600003 1452335.1327)
 Ring Self-intersection | POINT(469907.558600003 1438040.1327)
 Ring Self-intersection | POINT(471767.558600002 1438270.1327)
 Ring Self-intersection | POINT(473937.558600003 1473425.1327)
 Ring Self-intersection | POINT(473992.558600002 1459730.1327)
 Ring Self-intersection | POINT(475692.558600003 1461810.1327)
 Ring Self-intersection | POINT(475957.558600003 1438385.1327)
 Ring Self-intersection | POINT(481887.558600003 1462810.1327) <--####
 Ring Self-intersection | POINT(482742.558600003 1437200.1327)
 Ring Self-intersection | POINT(485862.558600003 1478445.1327)
(10 rows)


SELECT reason(ST_IsValidDetail(wkb_geometry)),
ST_AsText(location(ST_IsValidDetail(wkb_geometry))) as location FROM
"0601_cobertura_choluteca" WHERE St_IsValid(wkb_geometry)=false ORDER BY
1,2;

         reason         |               location
------------------------+--------------------------------------
 Ring Self-intersection | POINT(464742.558600003 1452335.1327)
 Ring Self-intersection | POINT(469907.558600003 1438040.1327)
 Ring Self-intersection | POINT(471767.558600002 1438270.1327)
 Ring Self-intersection | POINT(473937.558600003 1473425.1327)
 Ring Self-intersection | POINT(473992.558600002 1459730.1327)
 Ring Self-intersection | POINT(475692.558600003 1461810.1327)
 Ring Self-intersection | POINT(475957.558600003 1438385.1327)
 Ring Self-intersection | POINT(482742.558600003 1437200.1327)
 Ring Self-intersection | POINT(485862.558600003 1478445.1327)
 Self-intersection      | POINT(489932.558600003 1478650.1327) <--####
(10 rows)

Stefano

Il giorno 7 dicembre 2017 13:12, <[hidden email]> ha scritto:

> On Thu, 7 Dec 2017 12:28:16 +0100, Stefano Romanelli wrote:
>
>> Buongiorno a tutti,
>>
>> ho il seguente problema con una serie di shape file relativi all'uso suolo
>> dell'Honduras ad es [0]:
>>
>> in pratica GDAL (OGRINFO), QGIS e GRASS GIS identificano una serie di aree
>> sovrapposte (aree molto grosse, non piccole sovrapposizioni), mentre
>> SPATIALITE, POSTGIS, ARCVIEW 3.2 e ARCMAP non le identificano e le aree
>> interrogate (doppie per i software prima citati) forniscono le risposte
>> giuste sulla classe di uso suolo.
>>
>>
> Ciao Stefano,
>
> nessuno dei sw da te citati e' in grado di calcolarsi autonomamente le
> operazioni geometriche (come p.es. le intersezioni/sovrapposizioni etc);
> tutti quanti (almeno quelli FLOSS/GFOSS) delegano questi lavori alla
> libreria GEOS; non ho idea di cosa usino ArcView ed ArcMap, suppongo
> roba loro proprietaria.
>
> il problema e' che la GEOS e' disponibile in tante versioni successive,
> che a volte possono fornire risultati differenti (p.es. perche' si e'
> scoperto in seguito che c'era qualche bacarozzolo che e' poi stato
> eliminato  e risolto nelle versioni successive).
>
> vedo che tu riporti le versioni per svariati pacchetti, ma quello
> che sarebbe realmente significativo sarebbe andare a vedere quale
> versione della GEOS viene realmente utilizzata caso per caso.
>
> nota: molto spesso questi "risultati strani" sono causati da
> geometrie sporche che possono trarre in inganno gli algoritmi
> di calcolo delle relazioni spaziali.
> ti suggerirei di verificare questo aspetto, p.es. utilizzando
> la funzione ST_IsValid disponibile sia sotto PostGIS che
> sotto SpatiaLite.
> nel caso in cui effettivamente nei tuoi datasets ci fossero
> delle geometrie invalide dovresti riuscire a correggerle
> automaticamente usando la ST_MakeValid (anche questa supportata
> tanto da PostGIS come da SpatiaLite).
>
> 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.
> 801 iscritti al 19/07/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.
801 iscritti al 19/07/2017