lentezza di QGIS o del portatile?
Locked
lentezza di QGIS o del portatile?
 
|
Ciao a tutti!
Chiedo scusa per la domanda, ma forse qualcuno saprà la risposta. Utilizzo QGIS (da due anni) su un portatile con Windows Vista (32 bit), processore Intel Celeron (single core) 2,0 GHz, 2 GB RAM DDR2, scheda grafica integrata. Il problema non è nuovo. Di che si tratta: per esempio, ho convertito il DEM (raster, ottenuto con GRASS) in un file vettoriale e voglio colorare questo strato con colore continuo (diciamo dal giallo al marrone) oppure con un simbolo graduato (n classi). Per mostrare il risultato sullo schermo ci vogliono 40-50 secondi (in questo tempo non utilizzo un altro programma). Il tempo menzionato corrisponde a un file .shp di 16228 KB (una piccolissima regione). Parlo di un solo stato caricato in QGIS, perché i tempi di risposta sono più lunghi quando ho più stati caricati (minuti interi...). Così, spreco molto tempo. Mi chiedo se fosse il problema di QGIS oppure delle scarse risorse del portatile. Un altro portatile più potente (processore i5- 2,53 GHz o i7, 4 GB RAM DDR3 o 8 GB, scheda grafica dedicata di 1 o 2 GB, disco a 7200 rpm ecc.) potrebbe risolvere il problema? E' il problema di QGIS? Grazie in anticipo, Gabriela P.S. Scusatemi gli errori di lingua, per favore. _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 485 iscritti al 20.11.2010 |
|
|
Il giorno lun, 10/01/2011 alle 13.42 +0000, Gabriela Osaci Costache ha
scritto: > Il problema non è nuovo. Di che si tratta: per esempio, ho convertito > il DEM (raster, ottenuto con GRASS) in un file vettoriale e voglio > colorare questo strato con colore continuo (diciamo dal giallo al > marrone) oppure con un simbolo graduato (n classi). Per mostrare il > risultato sullo schermo ci vogliono 40-50 secondi (in questo tempo non > utilizzo un altro programma). Il tempo menzionato corrisponde a un > file .shp di 16228 KB (una piccolissima regione). Parlo di un solo > stato caricato in QGIS, perché i tempi di risposta sono più lunghi > quando ho più stati caricati (minuti interi...). Così, spreco molto > tempo. Puoi verificare che non ci siano errori topologici? Quelli rallentano molto il rendering, credo. Saluti. -- http://www.faunalia.it/pc _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 485 iscritti al 20.11.2010 |
Re: lentezza di QGIS o del portatile?
|
|
Grazie tanto del suggerimento. Ho controllato sei o sette stati con il plugin "controlla validità geometria" di fTools. Per tre di loro si verificano errori (tra 3 e 6 errori/strato). Non sono sicura: per pulirli devo utilizzare v.clean di GRASS (quale modulo)? C'è un'altra possibilità? Devo aggiungere che il rallentamento di QGIS si verifica con i strati vettoriali di cui raccontavo (derivati da stati raster di GRASS o il risultato di v.overlay.and) anche quando voglio spostare, ingrandire o rimpicciolire l'immagine sullo schermo e anche nel modulo di stampa. Per questo motivo credevo che fosse la colpa delle caratteristiche del portatile. Grazie, Gabriela Da: Paolo Cavallini <[hidden email]> A: Gabriela Osaci Costache <[hidden email]> Cc: [hidden email] Inviato: Lun 10 gennaio 2011, 18:17:19 Oggetto: Re: [Gfoss] lentezza di QGIS o del portatile? Il giorno lun, 10/01/2011 alle 13.42 +0000, Gabriela Osaci Costache ha scritto: > Il problema non è nuovo. Di che si tratta: per esempio, ho convertito > il DEM (raster, ottenuto con GRASS) in un file vettoriale e voglio > colorare questo strato con colore continuo (diciamo dal giallo al > marrone) oppure con un simbolo graduato (n classi). Per mostrare il > risultato sullo schermo ci vogliono 40-50 secondi (in questo tempo non > utilizzo un altro programma). Il tempo menzionato corrisponde a un > file .shp di 16228 KB (una piccolissima regione). Parlo di un solo > stato caricato in QGIS, perché i tempi di risposta sono più lunghi > quando ho più stati caricati (minuti interi...). Così, spreco molto > tempo. Puoi verificare che non ci siano errori topologici? Quelli rallentano molto il rendering, credo. Saluti. -- http://www.faunalia.it/pc _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 485 iscritti al 20.11.2010 |
|
|
Il giorno lun, 10/01/2011 alle 19.15 +0000, Gabriela Osaci Costache ha
scritto: > verificano errori (tra 3 e 6 errori/strato). Non sono sicura: per > pulirli devo utilizzare v.clean di GRASS (quale modulo)? C'è un'altra > possibilità? Credo che grass sia la scelta migliore in questo contesto. > Devo aggiungere che il rallentamento di QGIS si verifica con i strati > vettoriali di cui raccontavo (derivati da stati raster di GRASS o il > risultato di v.overlay.and) ma, aspetta, i vettori sono shp esportati da grass? > anche quando voglio spostare, ingrandire o rimpicciolire l'immagine > sullo schermo e anche nel modulo di stampa. Per questo motivo credevo > che fosse la colpa delle caratteristiche del portatile. Io farei cosi': - verificherei se la lentezza avviene solo per determinati strati - ripulirei quelli - proverei di nuovo - se non funziona, metterei a disposizione gli strati in modo che anche altri possano fare prove. In ogni caso, dubito che la potenza di calcolo del portatile c'entri molto: ho usato qgis anche su netbooks, e rimane piuttosto usabile. Saluti. -- http://www.faunalia.it/pc _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 485 iscritti al 20.11.2010 |
Re: lentezza di QGIS o del portatile?
|
|
Il 11 gennaio 2011 09:07, Paolo Cavallini <[hidden email]> ha scritto:
> In ogni caso, dubito che la potenza di calcolo del portatile c'entri > molto: ho usato qgis anche su netbooks, e rimane piuttosto usabile. > confermo, uso quasi quotidianamente qgis su un netbook intel atom con 1 gb di ram e non ho grossi problemi > Saluti. > -- > http://www.faunalia.it/pc > -- ciao Luca www.lucadelu.org _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 485 iscritti al 20.11.2010 |
Re: lentezza di QGIS o del portatile?
|
|
In reply to this post by pcav
Sì, i vettori sono shp prodotti in GRASS (sotto QGIS), caricati in QGIS e poi salvati (Layer - Salva con nome...). Ho verificato: la lentezza avviene solo per questi stati (DEM convertito da raster a vettore, shp ottenuti con v.overlay.and, per esempio DEM + gli spazi coperti dai boschi ecc.), dunque stati pesanti. Oggi ho avuto l'idea (non so come non l'ho avuta prima...) di aprire alcuni degli stati con problemi su un desktop della mia facoltà (che non è nuovo e troppo performante). Sorpresa: lo strato che era aperto in 50 secondi dal mio portatile, è stato aperto in solo 4 (quattro!) secondi. Quasi la stessa velocità (2-3 secondi) per spostare, ingrandire o rimpicciolire l'immagine sullo schermo (senza lo smarrimento dell'immagine, perché da me lo schermo rimane bianco mentre il portatile sta "pensando", dopo di che ricomporre lentamente l'immagine). Dunque, ringrazio tutti per l'aiuto e direi che fosse il problema del mio portatile. Saluti. Gabriela Da: Paolo Cavallini <[hidden email]> A: Gabriela Osaci Costache <[hidden email]> Cc: [hidden email] Inviato: Mar 11 gennaio 2011, 10:07:30 Oggetto: Re: [Gfoss] lentezza di QGIS o del portatile? Il giorno lun, 10/01/2011 alle 19.15 +0000, Gabriela Osaci Costache ha scritto: > verificano errori (tra 3 e 6 errori/strato). Non sono sicura: per > pulirli devo utilizzare v.clean di GRASS (quale modulo)? C'è un'altra > possibilità? Credo che grass sia la scelta migliore in questo contesto. > Devo aggiungere che il rallentamento di QGIS si verifica con i strati > vettoriali di cui raccontavo (derivati da stati raster di GRASS o il > risultato di v.overlay.and) ma, aspetta, i vettori sono shp esportati da grass? > anche quando voglio spostare, ingrandire o rimpicciolire l'immagine > sullo schermo e anche nel modulo di stampa. Per questo motivo credevo > che fosse la colpa delle caratteristiche del portatile. Io farei cosi': - verificherei se la lentezza avviene solo per determinati strati - ripulirei quelli - proverei di nuovo - se non funziona, metterei a disposizione gli strati in modo che anche altri possano fare prove. In ogni caso, dubito che la potenza di calcolo del portatile c'entri molto: ho usato qgis anche su netbooks, e rimane piuttosto usabile. Saluti. -- http://www.faunalia.it/pc _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 485 iscritti al 20.11.2010 |
|
|
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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 485 iscritti al 20.11.2010 |
Re: lentezza di QGIS o del portatile?
|
|
Grazie mille del suggerimento, proverò! Avevo osservato l'effetto a quadretti, ma non ho pensato a una semplificazione. Ciao. Gabriela Da: "[hidden email]" <[hidden email]> A: Gabriela Osaci Costache <[hidden email]>; [hidden email] Inviato: Mar 11 gennaio 2011, 20:05:27 Oggetto: Re: [Gfoss] lentezza di QGIS o del portatile? 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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 485 iscritti al 20.11.2010 |
|
|
In reply to this post by Gabriela Osaci Costache
Si, in grass c'è l'ottimo v.generalize
--- http://faunalia.it/pc ----- Reply message -----
On Tue, 11 Jan 2011 17:28:14 +0000 (GMT), Gabriela Osaci Costache
wrote
Da: [hidden email] Data: mar, gen 11, 2011 19:05 Oggetto: [Gfoss] lentezza di QGIS o del portatile? A: "Gabriela Osaci Costache" <[hidden email]>, <[hidden email]> > (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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 485 iscritti al 20.11.2010 |
Re: lentezza di QGIS o del portatile?
|
|
2011/1/11 [hidden email] <[hidden email]>:
> 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 :) 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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 485 iscritti al 20.11.2010 |
|
|
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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 485 iscritti al 20.11.2010 |
|
|
In reply to this post by Paolo Corti
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 :-P ST_Simplify(), ST_SimplifyPreserveTopology() sempre naturalmente su base GEOSSimplify() e GEOSTopologyPreserveSimplify() gira gira, la zuppa è sempre quella :-) ciao Sandro _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 485 iscritti al 20.11.2010 |
Re: generalize (era: lentezza di QGIS o del portatile?)
|
|
In reply to this post by pcav
2011/1/11 Paolo Cavallini <[hidden email]>:
> 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 ;) 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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 485 iscritti al 20.11.2010 |
|
|
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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 485 iscritti al 20.11.2010 |
Re: generalize (era: lentezza di QGIS o del portatile?)
|
|
> 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 _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 485 iscritti al 20.11.2010 |
|
|
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 ;) Saluti. -- Paolo Cavallini: http://www.faunalia.it/pc _______________________________________________ Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione [hidden email] http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss Questa e' una lista di discussione pubblica aperta a tutti. Non inviate messaggi commerciali. I messaggi di questa lista non rispecchiano necessariamente le posizioni dell'Associazione GFOSS.it. 485 iscritti al 20.11.2010 |
«
Return to Gfoss -- Geographic Free and Open Source Software - Italian mailing list
|
1 view|%1 views
| Free forum by Nabble | Edit this page |