Re: [Gfoss] aree sovrapposte in shape file solo per alcuni software
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.55863 1452335.1327)
Ring Self-intersection | POINT(469907.55863 1438040.1327)
Ring Self-intersection | POINT(471767.55862 1438270.1327)
Ring Self-intersection | POINT(473937.55863 1473425.1327)
Ring Self-intersection | POINT(473992.55862 1459730.1327)
Ring Self-intersection | POINT(475692.55863 1461810.1327)
Ring Self-intersection | POINT(475957.55863 1438385.1327)
Ring Self-intersection | POINT(481887.55863 1462810.1327) <--
Ring Self-intersection | POINT(482742.55863 1437200.1327)
Ring Self-intersection | POINT(485862.55863 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.55863 1452335.1327)
Ring Self-intersection | POINT(469907.55863 1438040.1327)
Ring Self-intersection | POINT(471767.55862 1438270.1327)
Ring Self-intersection | POINT(473937.55863 1473425.1327)
Ring Self-intersection | POINT(473992.55862 1459730.1327)
Ring Self-intersection | POINT(475692.55863 1461810.1327)
Ring Self-intersection | POINT(475957.55863 1438385.1327)
Ring Self-intersection | POINT(482742.55863 1437200.1327)
Ring Self-intersection | POINT(485862.55863 1478445.1327)
Self-intersection | POINT(489932.55863 1478650.1327) <--
(10 rows)
Stefano
Il giorno 7 dicembre 2017 13:12, 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
Re: [Gfoss] aree sovrapposte in shape file solo per alcuni software
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
[Gfoss] aree sovrapposte in shape file solo per alcuni software
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 ___ 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
