Il giorno 5 febbraio 2016 08:54, NicoPez <[hidden email]> ha scritto:
Beh! prova a scaricare le infrastrutture dal PCN servizio WFS: http://www.pcn.minambiente.it/GN/accesso-ai-servizi/servizi-di-download/wfs 43°51'0.54"N 10°34'27.62"E - EPSG:4326 “Se la conoscenza deve essere aperta a tutti, perchè mai limitarne l’accesso?” R. Stallman _______________________________________________ [hidden email] 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. 808 iscritti al 30.01.2015 |
In reply to this post by pigreco
Ciao Pigreco, ho letto ora tutti i vostri passaggi e visionato tutti i file.
Dal file input hai fatto il buffer e ti ha creato una nuova linea, poi come hai fatto a creare il file "out_dissolveall_input"? mi sa che devo ripassare un po' di basi.. :( Adesso vedo il link dele servizio WMS che mi hai condiviso :) Grazie! |
Il giorno 5 febbraio 2016 09:14, NicoPez <[hidden email]> ha scritto:
Beh! quello è un problema un pò diverso, si tratta di realizzare un poligono partendo da una linea chiusa; tu hai linee non chiuse. comunque il dissolveall puoi farlo da: vettore=> strumenti di geoprocessing => dissolvenza; tra le varie opzioni vi è sissolvi tutto Salvatore Fiandaca mobile.:<a href="tel:%2B39%20327.493.8955" value="+393274938955" target="_blank">+39 327.493.8955 m: [hidden email] 43°51'0.54"N 10°34'27.62"E - EPSG:4326 “Se la conoscenza deve essere aperta a tutti, perchè mai limitarne l’accesso?” R. Stallman _______________________________________________ [hidden email] 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. 808 iscritti al 30.01.2015 |
In reply to this post by stefano campus
----- Messaggio originale ----- Da: "stefano campus" <[hidden email]> A: [hidden email] Inviato: Martedì, 2 febbraio 2016 0:13:03 Oggetto: Re: [Gfoss] Problema: da linee a poligoni prima di lanciare le funzioni nei vari software, avevo verificato in qgis che non ci fossero problemi nel file di input; il "check geometry validity" non aveva rilevato alcun errore. dopo il post di totò, ho provato con v.clean (cleaning tool: snap) se ci fossero dei problemi ed in effetti ne ha rilevato un po'. in pratica i segmenti di input non erano effettivamente tutti connessi, anche se ad occhio nudo io non sono riuscito a vedere le discontinuità. comunque, questa maledetta estensione di arcview è di bocca buona e risolve anche i problemi di connessione. su... c'è qualche ex "avenuista" provetto, oggi pythonista convinto, magari torinese, magari di un ente pubblico che protegge l'ambiente, che ha voglia di guardare lo script e provare a tradurlo in un linguaggio più gradito a tutti? pago in birrette! ;-) s. ps: ogni riferimento a persone è propriamente voluto :-D Ciao, mastico ancora avenue. guardando lo script l'unico comando "interessante" (gli altri sono lettura dei record, esplosione in segmenti flip e ricomposizione, insomma cose necessarie) è proprio una "clean". shpin.Clean riga 161 insomma viene appplicata una clean sulla polyline. riporto dal manuale di Avenue. Clean: Returns aPolyLine cleaned by applying Connect request. A clean PolyLine contains no nodes where only two parts meet - these nodes are removed in the cleaning process to connect the parts. Syntax aPolyLine.Clean Returns PolyLine Il Connet request: Returns aPolyLine, with optimized number of parts. If end points of parts in a PolyLine are considered nodes in a graph, the resulting PolyLine has no nodes of valence two. This means that if two parts of aPolyLine share a particular node, these two parts will be merged into one part. If three parts of aPolyLine share a particular node, these three parts will remain as separate parts. Syntax aPolyLine.Connect Returns PolyLine Saluti marco _______________________________________________ [hidden email] 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. 808 iscritti al 30.01.2015 |
Il giorno Fri, 5 Feb 2016 10:08:13 +0100 (CET)
GUIDUCCI Marco <[hidden email]> ha scritto: ciao, > ----- Messaggio originale ----- > Da: "stefano campus" <[hidden email]> > A: [hidden email] > Inviato: Martedì, 2 febbraio 2016 0:13:03 > Oggetto: Re: [Gfoss] Problema: da linee a poligoni > > ...... > su... c'è qualche ex "avenuista" provetto, oggi pythonista convinto, > magari torinese, magari di un ente pubblico che protegge l'ambiente, > che ha voglia di guardare lo script e provare a tradurlo in un > linguaggio più gradito a tutti? > ...... > > Ciao, > mastico ancora avenue. > guardando lo script l'unico comando "interessante" (gli altri sono > lettura dei record, esplosione in segmenti flip e ricomposizione, > insomma cose necessarie) è proprio una "clean". > ....... chiedo scusa, forse ho seguito male il thread, ma sono rimasto disorientato dal sovrapporsi di un discorso di polilinea con buffer (che andrebbe bene se le strade avessero calibro costante) rispetto al problema di trasformare polilinee delimitanti la sede stradale in poligoni (ad es. dati catastali); se il problema è quest'ultimo e senza voler banalizzare, ma anche senza essere _esperti_ di avenue e python, il problema non appare insormontabile e pyqgis + gdal/ogr hanno tutti gli strumenti utili alla bisogna; se qualcuno decidesse di affrontare il problema io qualche idea ce l'ho e darei volentieri una mano, se gradita; > Saluti > marco ciao, giuliano PS: oltre a non essere avenuista nè pythonista, non sono nemmeno torinese nè dipendente pubblico, ciò nonostante le birrette del presidente vanno bene, il problema forse è l'origine e il numero: immagino Ichnusa e potrebbe andare bene, sul numero dove vogliamo collocarci? _______________________________________________ [hidden email] 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. 808 iscritti al 30.01.2015 |
On Fri, 5 Feb 2016 12:19:47 +0100
giulianc51 <[hidden email]> wrote: > chiedo scusa, forse ho seguito male il thread, ma sono rimasto > disorientato dal sovrapporsi di un discorso di polilinea con buffer (che > andrebbe bene se le strade avessero calibro costante) rispetto al > problema di trasformare polilinee delimitanti la sede stradale in > poligoni (ad es. dati catastali); > > se il problema è quest'ultimo e senza voler banalizzare, ma anche senza > essere _esperti_ di avenue e python, il problema non appare > insormontabile e pyqgis + gdal/ogr hanno tutti gli strumenti utili alla > bisogna; se qualcuno decidesse di affrontare il problema io qualche idea > ce l'ho e darei volentieri una mano, se gradita; il problema era che il risultato ottenuto dallo script Avenue arrivava ad una soluzione, mentre le "normali" procedure eseguite in grass o Qgis pare di no. Qualcuno ha fatto delle prove ed ha fatto notare che se la geometria è "pulita" anche con grass e/o QGis si ottiene il risultato. Pare quindi che condizione necessaria per ottenere dei poligoni buoni sia la correttezza delle polilinee di input. Analizzando lo script di Avenue si vede che anche in questo caso è chimata una procedura di Clean. Quindi nessun mistero sulle potenzialità miracolose di Avenue o sulla sua "bocca buona". Basta eseguire le solite procedure in altro ambiente. Tutto qui. -- Marco Guiducci <[hidden email]> Firenze, via di Novoli 26 055 4383194 _______________________________________________ [hidden email] 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. 808 iscritti al 30.01.2015 |
Il giorno Fri, 5 Feb 2016 15:30:52 +0100
Marco Guiducci <[hidden email]> ha scritto: ciao Marco, > On Fri, 5 Feb 2016 12:19:47 +0100 > giulianc51 <[hidden email]> wrote: > > > > chiedo scusa, forse ho seguito male il thread, ma sono rimasto > > disorientato dal sovrapporsi di ..... > > se il problema è quest'ultimo e senza voler banalizzare, ma anche > > senza essere _esperti_ di avenue e python, il problema non appare > > insormontabile e ......... > > il problema era che il risultato ottenuto dallo script Avenue > arrivava ad una soluzione, mentre le "normali" procedure eseguite in > grass o Qgis pare di no. ...... > ............. Quindi nessun mistero sulle > potenzialità miracolose di Avenue o sulla sua "bocca buona". Basta > eseguire le solite procedure in altro ambiente. Tutto qui. ti ringrazio del conciso ed esauriente riepilogo; per mia colpa non ho esplicitato un pensiero recondito: qualcuno aveva parlato di linee apparentemente connesse, ma in realtà spezzate; in tal caso la pulizia non è sufficiente e le procedure solite non bastano, occorre immaginare qualche algoritmo di ricostruzione, magari da consegnare in un apposito plugin; mi muovevo in questo contesto, scusa se non sono stato completamente chiaro in precedenza; grazie, ciao, giuliano _______________________________________________ [hidden email] 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. 808 iscritti al 30.01.2015 |
Il giorno 5 febbraio 2016 16:50, giulianc51 <[hidden email]> ha scritto:
gli shapefile allegati presentavano errori topologici e non geometrici, attraverso l'uso di v.clean con opzione snap siamo riusciti a risolvere il tutto. questa opzione (usata correttamente) risolve i problemi di mal connessione tra i vertici della polilinea. 43°51'0.54"N 10°34'27.62"E - EPSG:4326 “Se la conoscenza deve essere aperta a tutti, perchè mai limitarne l’accesso?” R. Stallman _______________________________________________ [hidden email] 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. 808 iscritti al 30.01.2015 |
Ciao Pigreco, ho provato la funzione v.clean con opzione snap. Ma che parametri hai messo per eliminare gli errori?
|
Il giorno 16 febbraio 2016 14:46, NicoPez <[hidden email]> ha scritto:
Ciao, per scegliere il parametro di snap devi analizzare gli errori e prendere quello più grande: se per esempio la distanza tra due vertici è 8 prendi come parametro 10. saluti. 43°51'0.54"N 10°34'27.62"E - EPSG:4326 “Se la conoscenza deve essere aperta a tutti, perchè mai limitarne l’accesso?” R. Stallman _______________________________________________ [hidden email] 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. 808 iscritti al 30.01.2015 |
Gli errori topologici li analizzo da "validatore topologico"? Perché lì non mi dice il valore dell'errore mi sembra Il giorno 16 febbraio 2016 15:10, pigreco [via Gfoss -- Geographic Free and Open Source Software - Italian mailing list] <[hidden email]> ha scritto:
Ing. Nicola Pezzotta Ingegnere civile ambientale | Tecnico GIS, esperto Open Source. Guida naturalistica o ambientale escursionistica. Founder, blogger e Seo Strategist presso http://www.coninfacciaunpodisole.it/ Strada Faleriense, 4265 | 63811 Sant’Elpidio a Mare (FM) Mail: [hidden email] | [hidden email] Tel. 333.3626495 |
Finalmente sono arrivato alla risoluzione, soprattutto grazie all'aiuto di Pigreco, ma grazie lo stesso a tutti! :)
Per correttezza vi scrivo i passaggi così se qualcuno si dovesse trovare in difficoltà con lo stesso problema magari sa cosa fare. Dovevo colorare l'interno della strada di un layer lineare estrapolato da un dxf. 1. Avevo il dxf della carta tecnica e ho estrapolato le strade e convertito in shape file. 2. Queste linee avevano numerosi errori topologici (trovati attraverso "validatore topologico"). Eliminati tramite il plugin "v.clean". 3. Alcune strade non potevano diventare poligoni perché non chiuse. Per chiuderle e non farlo manualmente una per una Pigreco mi ha segnalato il plugin "join multiple lines". Molto utile! 4. Ora facendo da linee a poligono si ha il risultato atteso. Ciao a tutti! |
Grazie a te NicoPez per la condivisione e soprattutto per aver scritto questa ultima email (cosi si fa!!!) PS: potrebbe essere utile in questi casi anche il seguente plugin: saluti. Il giorno 19 febbraio 2016 11:18, NicoPez <[hidden email]> ha scritto: Finalmente sono arrivato alla risoluzione, soprattutto grazie all'aiuto di 43°51'0.54"N 10°34'27.62"E - EPSG:4326 “Se la conoscenza deve essere aperta a tutti, perchè mai limitarne l’accesso?” R. Stallman _______________________________________________ [hidden email] 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. 808 iscritti al 30.01.2015 |
Administrator
|
In reply to this post by Marco Guiducci-3
scusate, mi ero perso il proseguimento della discussione.
grazie mille marco per la tua analisi dello script di arcview. quello che quindi a me sembrava una magia oppure un sorvolare su correttezza geometrica di arcview, in realtà nascondeca un'operazione di pulizi ageometrica iniziale. ora provo con altri dataset e vediamo che cosa succede. vi ringrazio molto. @giuliano: la macchinette delle birrette è sempre in stand by, mai spenta. appena ci si vede la si riavvia tutt'insieme :-) s. |
Il giorno Fri, 19 Feb 2016 06:26:45 -0700 (MST)
stefano campus <[hidden email]> ha scritto: ciao, > ....... > @giuliano: la macchinette delle birrette è sempre in stand by, mai > spenta. appena ci si vede la si riavvia tutt'insieme :-) guarda che ti sei esposto in pubblico ! > s. ciao, g. _______________________________________________ [hidden email] 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. 808 iscritti al 30.01.2015 |
Free forum by Nabble | Edit this page |