[Gfoss] aree sovrapposte in shape file solo per alcuni software

[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, <a.furieri a lqt.it> 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
>
> _______________________________________________
> Gfoss a 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.
> 801 iscritti al 19/07/2017