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@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@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