[Gfoss] lentezza di QGIS o del portatile?

Si, in grass c’è l’ottimo v.generalize


http://faunalia.it/pc

----- Reply message -----
Da: a.furieri@lqt.it
Data: mar, gen 11, 2011 19:05
Oggetto: [Gfoss] lentezza di QGIS o del portatile?
A: “Gabriela Osaci Costache” gabrielacatalinaosaci@yahoo.it, gfoss@lists.gfoss.it

On Tue, 11 Jan 2011 17:28:14 +0000 (GMT), Gabriela Osaci Costache wrote

(DEM convertito da raster a vettore)

Gabriela,
anche a me è capitato (per caso) di incontrare forti
problemi di lentezza usando il dataset GADM:
http://www.gadm.org/

La causa è abbastanza semplice da identificare: quando
converti un DEM come vector, si vengono facilmente a creare
dei POLYGONs (oppure dei LINESTRINGs) pesantissimi, con
moltissime decine di migliaia di vertici.
p.es. vedi GADM in paesi come il Canada o l’Australia,
che hanno coste assai estese e con un contorno
fortemente frastagliato (baie, promontori, fiordi …)

Fai uno zoom al massimo livello di ingrandimento: e scoprirai
come in pratica per ogni singola cella del DEM originale è stato
inserito un punto nel vector (effetto a gradini/quadretti).

Soluzione: applica alle geometrie una funzione di semplificazione
tipo Douglas-Peukert.
In genere nei DBMS Spatial la trovi definita come ST_Simplify()
Ma non dubito che anche QGIS e/o GRASS la supportano in
qualche modo.

ciao Sandro

2011/1/11 cavallini@faunalia.it <cavallini@faunalia.it>:

Si, in grass c'è l'ottimo v.generalize

volevo dimostrare che - al solito - quello che si riesce a fare con
GRASS si riesce a fare con GDAL.
Ma curiosamente non c'e' un'opzione per il generalize in ogr2ogr
invece (mentre ce n'e' una che fa l'opposto, segmentize)
E, aggiungo, sarebbe semplice implementarla, tra l'altro, visto che
nella classe OGRGeometry e' implementato il metodo Simplify [1] (via
GEOS).
Che poi e' lo stesso algoritmo usato dal ST_Simplify [2] in PostGis (e
immagino anche in Spatialite).

C'avrei scommesso qualsiasi cosa :slight_smile:
P

[1] http://www.gdal.org/ogr/classOGRGeometry.html#fd3ea0ffa1e2994427032d0212206ccf
[2] http://postgis.refractions.net/docs/ST_Simplify.html

--
Paolo Corti
GIS specialist and web developer
web: http://www.paolocorti.net
twitter: @paolo_corti

Il giorno mar, 11/01/2011 alle 19.36 +0100, Paolo Corti ha scritto:

E, aggiungo, sarebbe semplice implementarla, tra l'altro, visto che
nella classe OGRGeometry e' implementato il metodo Simplify [1] (via
GEOS).

Attenzione! Quello che esiste in grass e' molto piu' sofisticato, da' la
possibilita' di scegliere un sacco di algoritmi e parametri, sia per il
generalize che per il suo simmetrico (smoothing), e *mantiene* la
coerenza topologica.
Con tutto il rispetto, non e' confrontabile con geos.

Saluti.
--
Paolo Cavallini: http://www.faunalia.it/pc

On Tue, 11 Jan 2011 19:36:36 +0100, Paolo Corti wrote

Che poi e' lo stesso algoritmo usato dal ST_Simplify [2] in PostGis
(e immagino anche in Spatialite).

ovvio che c'è anche in SpatiaLite :stuck_out_tongue:

ST_Simplify(), ST_SimplifyPreserveTopology()

sempre naturalmente su base GEOSSimplify()
e GEOSTopologyPreserveSimplify()
gira gira, la zuppa è sempre quella :slight_smile:

ciao Sandro

2011/1/11 Paolo Cavallini <cavallini@faunalia.it>:

Il giorno mar, 11/01/2011 alle 19.36 +0100, Paolo Corti ha scritto:

E, aggiungo, sarebbe semplice implementarla, tra l'altro, visto che
nella classe OGRGeometry e' implementato il metodo Simplify [1] (via
GEOS).

Attenzione! Quello che esiste in grass e' molto piu' sofisticato, da' la
possibilita' di scegliere un sacco di algoritmi e parametri, sia per il
generalize che per il suo simmetrico (smoothing), e *mantiene* la
coerenza topologica.
Con tutto il rispetto, non e' confrontabile con geos.

Ciao Paolo

hai perfettamente ragione :wink:

E' anche vero pero' che per la maggior parte degli use cases e'
sufficiente l'algoritmo piu' semplice, e il benefit di poter lavorare
direttamente sul dato originale senza dovere importare/esportare al
GRASS database e' a volte una caratteristica imprescindibile in molti
scenari.
Tra l'altro spulciando bene il TRAC di GDAL [0] ho scoperto che
ogr2ogr implementera' a breve un'opzione per generalizzare l'ogr di
output, certo con l'algoritmo semplificato, ma potrebbe poi essere
esteso ad algoritmi piu complessi (si evince leggendo i commenti).

Per quanto riguarda invece la tua osservazione sul mantenimento della
coerenza topologica penso di poter affermare con certezza che GEOS
gia' lo faccia, cosi' come JTS del quale e' una traduzione fedele [1],
guarda ad es la classe geos::simplify::TopologyPreservingSimplifier
[2]

un caro saluto
P

[0] http://trac.osgeo.org/gdal/ticket/966
[1] http://www.vividsolutions.com/jts/javadoc/com/vividsolutions/jts/simplify/package-tree.html
[2] http://geos.refractions.net/ro/doxygen_docs/html/classgeos_1_1simplify_1_1TopologyPreservingSimplifier.html

--
Paolo Corti
GIS specialist and web developer
web: http://www.paolocorti.net
twitter: @paolo_corti

Il giorno mer, 12/01/2011 alle 12.05 +0100, Paolo Corti ha scritto:

E' anche vero pero' che per la maggior parte degli use cases e'
sufficiente l'algoritmo piu' semplice, e il benefit di poter lavorare
direttamente sul dato originale senza dovere importare/esportare al
GRASS database e' a volte una caratteristica imprescindibile in molti
scenari.

Per quanto riguarda invece la tua osservazione sul mantenimento della
coerenza topologica penso di poter affermare con certezza che GEOS
gia' lo faccia, cosi' come JTS del quale e' una traduzione fedele [1],
guarda ad es la classe geos::simplify::TopologyPreservingSimplifier
[2]

Nono, dai retta: provaci, e vedrai che sostanzialmente non e' usabile
per niente di serio, a differenza di v.generalize.
Salutoni.
--
Paolo Cavallini: http://www.faunalia.it/pc

Nono, dai retta: provaci, e vedrai che sostanzialmente non e' usabile
per niente di serio, a differenza di v.generalize.
Salutoni.

Paolo

ti devo dare nuovamente ragione al 100%!
In effetti ingenuamente stavo pensando a linee, pero' con i poligoni
ci sono grossi problemi, e a tutti gli effetti in ambito FOSS4G GRASS
e' l'unico che gestisce al 100% la topologia.

Con PostGis (e quindi GEOS) si puo' ricorrere al PostGIS Topology Tool
[0], che e' pero' in alpha.
In questa discussione su gis.stackexchange [1] Ramsey da un altro
approccio al problema con PostGis (ovviamente si puo' replicare la
cosa con uno script GDAL): in sostanza da poligoni si passa a linee,
si semplificano, e poi si ricompongono i poligoni, in ogni caso niente
di lontanamente paragonabile a GRASS.

Per concludere: sicuramente l'opzione che stanno per mettere su
ogr2ogr di cui parlavo prima, per come e' concepita, se da un lato
funzionera' bene per feature lineare, d'altro lato provochera'
anomalie topologiche su feature poligonali

un saluto
P

[0] http://trac.osgeo.org/postgis/wiki/UsersWikiPostgisTopology
[1] http://gis.stackexchange.com/questions/178/simplifing-adjacent-polygons

--
Paolo Corti
GIS specialist and web developer
web: http://www.paolocorti.net
twitter: @paolo_corti

Il giorno mer, 12/01/2011 alle 20.19 +0100, Paolo Corti ha scritto:

Con PostGis (e quindi GEOS) si puo' ricorrere al PostGIS Topology Tool
[0], che e' pero' in alpha.

Si', ne so qualcosa :wink:
Saluti.
--
Paolo Cavallini: http://www.faunalia.it/pc