Buongiorno a tutti, qualcuno di voi sa se in PostGIS esiste una funzione per la riproiezione tramite punti omologhi simile a quella presente in GRASS (v.transform) ?
ATTENZIONE! Le informazioni contenute nella presente e-mail e nei documenti eventualmente allegati sono confidenziali. La loro diffusione, distribuzione e/o riproduzione da parte di terzi, senza autorizzazione del mittente è vietata e può violare il D. Lgs. 196/2003. In caso di ricezione per errore, Vogliate immediatamente informare il mittente del messaggio e distruggere la e-mail. ACHTUNG! Die in dieser Nachricht oder in den beigelegten Dokumenten beinhalteten Informationen sind streng vertraulich. Ihre Verbreitung und/oder ihre Wiedergabe durch Dritte ist ohne Erlaubnis des Absenders verboten und verstößt gegen das Legislativdekret 196/2003. Sollten Sie diese Mitteilung irrtümlicherweise erhalten haben, bitten wir Sie uns umgehend zu informieren und anschließend die Mitteilung zu vernichten. WARNING! This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclousure or distribution of the material in this e-mail is strictly forbidden and could be against the law (D. Lgs. 196/2003) _______________________________________________ [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. 750 iscritti al 18.3.2015 |
On Tue, 18 Aug 2015 10:37:47 +0200, Pietro D'Orio wrote:
> Buongiorno a tutti, > qualcuno di voi sa se in PostGIS esiste una funzione per la > riproiezione tramite punti omologhi simile a quella presente in GRASS > (v.transform) ? > Ciao Pietro, su base PostGIS non credo proprio che esista nulla di simile, ma se ti accontenti di un'implementazione Spatial SQL alternativa tutte queste funzionalita' sono supportate dall'ultima versione di SpatiaLite (4.3.0) ... e per inciso, sono largamente basate sul medesimo codice utilizzato da GRASS GIS (v.transform / v.rectify). https://www.gaia-gis.it/fossil/libspatialite/wiki?name=Affine+Transform https://www.gaia-gis.it/fossil/libspatialite/wiki?name=Ground+Control+Points ciao Sandro _______________________________________________ [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. 750 iscritti al 18.3.2015 |
In reply to this post by PietroR3
On Tue, Aug 18, 2015 at 10:37:47AM +0200, Pietro D'Orio wrote:
> Buongiorno a tutti, > qualcuno di voi sa se in PostGIS esiste una funzione per la riproiezione > tramite punti omologhi simile a quella presente in GRASS (v.transform) ? Questa ? http://postgis.net/docs/ST_Affine.html --strk; _______________________________________________ [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. 750 iscritti al 18.3.2015 |
In reply to this post by a.furieri
Ciao
2015-08-18 11:00 GMT+02:00 <[hidden email]>: > On Tue, 18 Aug 2015 10:37:47 +0200, Pietro D'Orio wrote: >> > su base PostGIS non credo proprio che esista nulla di simile, su postgis ST_affine richiede una matrice di trasformazione in ingresso, non ho mai avuto tempo di realizzarla, ma avevo trovato questo docuemnto interessante che spiega passo passo http://casoilresource.lawr.ucdavis.edu/software/postgis-spatially-enabled-relational-database-sytem/affine-transformation-operations-postgis/ Ciao _______________________________________________ [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. 750 iscritti al 18.3.2015 |
In reply to this post by Sandro Santilli
On Tue, 18 Aug 2015 11:13:34 +0200, Sandro Santilli wrote:
> On Tue, Aug 18, 2015 at 10:37:47AM +0200, Pietro D'Orio wrote: >> Buongiorno a tutti, >> qualcuno di voi sa se in PostGIS esiste una funzione per la >> riproiezione >> tramite punti omologhi simile a quella presente in GRASS >> (v.transform) ? > > Questa ? http://postgis.net/docs/ST_Affine.html > ciao Strk, giusto per mettere in luce le differenze tra le due implementazioni (postgis vs splite): entrambe supportano la ST_Affine() ma per usare materialmente questa funzione serve passare come argomento una matrice di trasformazione affine gia' completamente sviluppata in forma canonica, compito per nulla agevole e niente affatto banale. il modulo spatialite ti consente (in modo tutto sommato semplice) di svilupparti tutti i calcoli matriciali che servono per arrivare a definire accuratamente una roto-traslazione anche complessa. ed eventualmente (grazie al riuso del codice GRASS) puoi anche partire dall'approccio alternativo per "punti noti coincidenti" (Ground Control Point) con determinazione automatica dei relativi coefficienti di trasformazione polinomiale. viceversa tutta questa parte "di supporto" e' totalmente assente in PostGIS, che da per scontato che la matrice di trasformazione affine sia gia' nota a priori. ciao Sandro _______________________________________________ [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. 750 iscritti al 18.3.2015 |
2015-08-18 11:31 GMT+02:00 <[hidden email]>:
> ciao Strk, > viceversa tutta questa parte "di supporto" e' totalmente assente in > PostGIS, che da per scontato che la matrice di trasformazione affine > sia gia' nota a priori. Ecco una cosa interessante da aggiugere in postgis... Quanto costerebbe? Chi mi fa un preventivo? amefad _______________________________________________ [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. 750 iscritti al 18.3.2015 |
In reply to this post by a.furieri
semi OT: mi sono sempre domandato se sia concettualmente corretto applicare delle trasformazione non isometriche a dei vettoriali lineari o poligonali. Le linestring resterebbero rette, quando invece dovrebbe (in generale) diventare curve... giovanni Il giorno 18 agosto 2015 11:31, <[hidden email]> ha scritto: On Tue, 18 Aug 2015 11:13:34 +0200, Sandro Santilli wrote: Giovanni Allegri http://about.me/giovanniallegri Gis3W - http://gis3w.it _______________________________________________ [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. 750 iscritti al 18.3.2015 |
Per questo ci sono delle opportune funzioni di densificazione . Il 18/ago/2015 11:47 AM, "G. Allegri" <[hidden email]> ha scritto:
_______________________________________________ [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. 750 iscritti al 18.3.2015 |
Infatti Andrea. Questo potrebbe essere parte dell'algoritmo di trasformazione, che in base all'RMS della trasformazione potrebbe proporre la migliore densificazione che minimizzi lo scarto. giovanni Il giorno 18 agosto 2015 12:15, Andrea Peri <[hidden email]> ha scritto:
Giovanni Allegri http://about.me/giovanniallegri Gis3W - http://gis3w.it _______________________________________________ [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. 750 iscritti al 18.3.2015 |
In reply to this post by Andrea Peri
Per spiegare meglio:
il buon vecchio arcims della esri (prodotto ormai dismesso da tempo) , aveva un parametro che se attivato , quando trasformava da una linea in un altro sistema di riferimento a un altro, non si limitava a trasformare i vertici, ma densificava la linea, mettendo un certo numero di vertici extra. Questo per permettere appunto a una linea retta di diventare "curva". Ovviamente era piu' lento, e anche produceva roba piu' pesante visto che aveva piu' vertici, ma con ragione. A. Il 18 agosto 2015 12:15, Andrea Peri <[hidden email]> ha scritto: > Per questo ci sono delle opportune funzioni di densificazione . > Con esse si aumenta la densità di vertici di una linestring. Questo permette > che la retta diventi curva. O meglio da una linea retta passa a tante linee > più corte che rappresentano un tragitto non più rettilineo. > > Il 18/ago/2015 11:47 AM, "G. Allegri" <[hidden email]> ha scritto: >> >> semi OT: mi sono sempre domandato se sia concettualmente corretto >> applicare delle trasformazione non isometriche a dei vettoriali lineari o >> poligonali. Le linestring resterebbero rette, quando invece dovrebbe (in >> generale) diventare curve... >> >> giovanni >> >> Il giorno 18 agosto 2015 11:31, <[hidden email]> ha scritto: >>> >>> On Tue, 18 Aug 2015 11:13:34 +0200, Sandro Santilli wrote: >>>> >>>> On Tue, Aug 18, 2015 at 10:37:47AM +0200, Pietro D'Orio wrote: >>>>> >>>>> Buongiorno a tutti, >>>>> qualcuno di voi sa se in PostGIS esiste una funzione per la >>>>> riproiezione >>>>> tramite punti omologhi simile a quella presente in GRASS (v.transform) >>>>> ? >>>> >>>> >>>> Questa ? http://postgis.net/docs/ST_Affine.html >>>> >>> >>> ciao Strk, >>> >>> giusto per mettere in luce le differenze tra le due implementazioni >>> (postgis vs splite): entrambe supportano la ST_Affine() >>> >>> ma per usare materialmente questa funzione serve passare come argomento >>> una matrice di trasformazione affine gia' completamente sviluppata in >>> forma canonica, compito per nulla agevole e niente affatto banale. >>> >>> il modulo spatialite ti consente (in modo tutto sommato semplice) di >>> svilupparti tutti i calcoli matriciali che servono per arrivare a >>> definire accuratamente una roto-traslazione anche complessa. >>> ed eventualmente (grazie al riuso del codice GRASS) puoi anche partire >>> dall'approccio alternativo per "punti noti coincidenti" (Ground Control >>> Point) con determinazione automatica dei relativi coefficienti di >>> trasformazione polinomiale. >>> viceversa tutta questa parte "di supporto" e' totalmente assente in >>> PostGIS, che da per scontato che la matrice di trasformazione affine >>> sia gia' nota a priori. >>> >>> ciao Sandro >>> >>> _______________________________________________ >>> [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. >>> 750 iscritti al 18.3.2015 >> >> >> >> >> -- >> Giovanni Allegri >> http://about.me/giovanniallegri >> Gis3W - http://gis3w.it >> Ikare - http://ikare.it >> Twitter: https://twitter.com/_giohappy_ >> blog: http://blog.spaziogis.it >> GEO+ geomatica in Italia http://bit.ly/GEOplus >> >> _______________________________________________ >> [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. >> 750 iscritti al 18.3.2015 -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [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. 750 iscritti al 18.3.2015 |
E' proprio quello che intendevo ;) Il 18/ago/2015 12:24, "Andrea Peri" <[hidden email]> ha scritto:
Per spiegare meglio: _______________________________________________ [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. 750 iscritti al 18.3.2015 |
On Tue, 18 Aug 2015 12:41:47 +0200, G. Allegri wrote:
> E' proprio quello che intendevo ;) > > Il 18/ago/2015 12:24, "Andrea Peri" ha scritto: > >> Per spiegare meglio: >> >> il buon vecchio arcims della esri (prodotto ormai dismesso da >> tempo) , >> aveva un parametro che se attivato , quando trasformava da una >> linea >> in un altro sistema di riferimento a un altro, non si limitava a >> trasformare i vertici, ma densificava la linea, mettendo un certo >> numero di vertici extra. >> Questo per permettere appunto a una linea retta di diventare >> "curva". >> Ovviamente era piu' lento, e anche produceva roba piu' pesante >> visto che aveva piu' vertici, ma con ragione. >> ossia, in termini Spatial SQL (vale tanto per postgis come per splite): per ottenere un effetto assolutamente identico basta semplicemente richiamare la funzione ST_Segmentize() immediatamente prima di applicare la trasformazione affine. ST_Segmentize(geom, max_segment_length) la Segmentize ritorna una nuova geometria ottenuta trasformando tutti i Linestring o Polygon ricevuti in input in modo tale da "spezzare" ciascun singolo segmento in una sequenza di segmentini piu' corti, ciascuno dei quali e' individualmente non piu' lungo della soglia prefissata dall'argomento <max_segment_length>. e quindi in ultima analisi consente di densificare a piacere le geometrie da sottoporre a trasformazione. ciao Sandro _______________________________________________ [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. 750 iscritti al 18.3.2015 |
Pero' non va fatto in automatico, deve essere una azione voluta e ponderata.
Infatti la segmentize rishcia di rompere la eventuale precisione topologica del dato. Infatti, quando si va a segmentizzare per distanza, ogni linea viene segmentizzata autonomamente. Questo potrebbe comportare che i vertici di due linee sovrapposte che in partenza erano perfettamente coincidenti, poi non lo sono piu', perche' in una linea e nell'altra si sono aggiunti vertici in punti differenti. Questo e' quasi sicuro se le due linee sono percorse in senso opposto. e questo succede sicuramente se le due linee sono coincidenti e appartenenti a due poligoni confinanti. Ecco che si entra subito in un discorso di topologia. Un conto e' fare queste cose in un mondo topologico (in una vera struttura topologica) e un conto e' farle in un mondo simple-feature, dove appena tocchi qualcosa rompi degli equilibri fragilissimi. A. Il 18 agosto 2015 13:14, <[hidden email]> ha scritto: > On Tue, 18 Aug 2015 12:41:47 +0200, G. Allegri wrote: >> >> E' proprio quello che intendevo ;) >> >> Il 18/ago/2015 12:24, "Andrea Peri" ha scritto: >> >>> Per spiegare meglio: >>> >>> il buon vecchio arcims della esri (prodotto ormai dismesso da >>> tempo) , >>> aveva un parametro che se attivato , quando trasformava da una >>> linea >>> in un altro sistema di riferimento a un altro, non si limitava a >>> trasformare i vertici, ma densificava la linea, mettendo un certo >>> numero di vertici extra. >>> Questo per permettere appunto a una linea retta di diventare >>> "curva". >>> Ovviamente era piu' lento, e anche produceva roba piu' pesante >>> visto che aveva piu' vertici, ma con ragione. >>> > > ossia, in termini Spatial SQL (vale tanto per postgis come per splite): > per ottenere un effetto assolutamente identico basta semplicemente > richiamare la funzione ST_Segmentize() immediatamente prima di > applicare la trasformazione affine. > > ST_Segmentize(geom, max_segment_length) > > la Segmentize ritorna una nuova geometria ottenuta trasformando > tutti i Linestring o Polygon ricevuti in input in modo tale da > "spezzare" ciascun singolo segmento in una sequenza di segmentini > piu' corti, ciascuno dei quali e' individualmente non piu' lungo > della soglia prefissata dall'argomento <max_segment_length>. > e quindi in ultima analisi consente di densificare a piacere > le geometrie da sottoporre a trasformazione. > > ciao Sandro -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [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. 750 iscritti al 18.3.2015 |
Sicuro, questi meccanismi, volendo anche semiautomatici (segmentazione basata sull'errore della trasformazione) devono mantenere la correttezza topologica. Ovvio che su una struttura topologica questo viene da sé, altrimenti servono meccanismi più sofisticati, come nella semplificazione con preservamento della topologia. giovanni Il 18/ago/2015 13:32, "Andrea Peri" <[hidden email]> ha scritto:
Pero' non va fatto in automatico, deve essere una azione voluta e ponderata. _______________________________________________ [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. 750 iscritti al 18.3.2015 |
No, la semplificazione con preservamento della topologia preserva solo
la posizione dei nodi. Non nei vertici intermedi. Per cui la topologia e' comunque rovinata. A. Il 18 agosto 2015 13:55, G. Allegri <[hidden email]> ha scritto: > Sicuro, questi meccanismi, volendo anche semiautomatici (segmentazione > basata sull'errore della trasformazione) devono mantenere la correttezza > topologica. Ovvio che su una struttura topologica questo viene da sé, > altrimenti servono meccanismi più sofisticati, come nella semplificazione > con preservamento della topologia. > > giovanni > > Il 18/ago/2015 13:32, "Andrea Peri" <[hidden email]> ha scritto: >> >> Pero' non va fatto in automatico, deve essere una azione voluta e >> ponderata. >> Infatti la segmentize rishcia di rompere la eventuale precisione >> topologica del dato. >> >> Infatti, quando si va a segmentizzare per distanza, ogni linea viene >> segmentizzata autonomamente. >> Questo potrebbe comportare che i vertici di due linee sovrapposte che >> in partenza erano perfettamente coincidenti, poi non lo sono piu', >> perche' in una linea e nell'altra si sono aggiunti vertici in punti >> differenti. >> >> Questo e' quasi sicuro se le due linee sono percorse in senso opposto. >> e questo succede sicuramente se le due linee sono coincidenti e >> appartenenti a due poligoni confinanti. >> >> Ecco che si entra subito in un discorso di topologia. >> Un conto e' fare queste cose in un mondo topologico (in una vera >> struttura topologica) e un conto e' farle in un mondo simple-feature, >> dove appena tocchi qualcosa rompi degli equilibri fragilissimi. >> >> A. >> >> >> Il 18 agosto 2015 13:14, <[hidden email]> ha scritto: >> > On Tue, 18 Aug 2015 12:41:47 +0200, G. Allegri wrote: >> >> >> >> E' proprio quello che intendevo ;) >> >> >> >> Il 18/ago/2015 12:24, "Andrea Peri" ha scritto: >> >> >> >>> Per spiegare meglio: >> >>> >> >>> il buon vecchio arcims della esri (prodotto ormai dismesso da >> >>> tempo) , >> >>> aveva un parametro che se attivato , quando trasformava da una >> >>> linea >> >>> in un altro sistema di riferimento a un altro, non si limitava a >> >>> trasformare i vertici, ma densificava la linea, mettendo un certo >> >>> numero di vertici extra. >> >>> Questo per permettere appunto a una linea retta di diventare >> >>> "curva". >> >>> Ovviamente era piu' lento, e anche produceva roba piu' pesante >> >>> visto che aveva piu' vertici, ma con ragione. >> >>> >> > >> > ossia, in termini Spatial SQL (vale tanto per postgis come per splite): >> > per ottenere un effetto assolutamente identico basta semplicemente >> > richiamare la funzione ST_Segmentize() immediatamente prima di >> > applicare la trasformazione affine. >> > >> > ST_Segmentize(geom, max_segment_length) >> > >> > la Segmentize ritorna una nuova geometria ottenuta trasformando >> > tutti i Linestring o Polygon ricevuti in input in modo tale da >> > "spezzare" ciascun singolo segmento in una sequenza di segmentini >> > piu' corti, ciascuno dei quali e' individualmente non piu' lungo >> > della soglia prefissata dall'argomento <max_segment_length>. >> > e quindi in ultima analisi consente di densificare a piacere >> > le geometrie da sottoporre a trasformazione. >> > >> > ciao Sandro >> >> >> >> -- >> ----------------- >> Andrea Peri >> . . . . . . . . . >> qwerty àèìòù >> ----------------- -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [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. 750 iscritti al 18.3.2015 |
No, la semplificazione con preservamento della topologia preserva solo ??? Tra oggetti distinti ok, ma in una multipart viene preservata, come no?
Giovanni Allegri http://about.me/giovanniallegri Gis3W - http://gis3w.it _______________________________________________ [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. 750 iscritti al 18.3.2015 |
Non so se in una multiparte viene preservata.
Non ci conterei troppo. Ma comunque il problema e' tra oggetti distinti. La preservazione internamente a un oggetto (e un oggetto multiparte, cioe' coposto di 2 o piu'parti e' comunque un unico oggetto) e' meno del minimo. Un qualsiasi poligono anche il piu' fetido preso da solo se non ha invalidita' geometriche e' implicitamente topologico. La topologia e' una caratteristica che connota le relazioni tra oggetti distinti e diversi. E quindi non ha senso guardarla internamente a un singolo oggetto. A. Il 18 agosto 2015 14:24, G. Allegri <[hidden email]> ha scritto: >> No, la semplificazione con preservamento della topologia preserva solo >> la posizione dei nodi. >> >> Non nei vertici intermedi. >> Per cui la topologia e' comunque rovinata. > > > ??? > Tra oggetti distinti ok, ma in una multipart viene preservata, come no? > https://trac.osgeo.org/postgis/wiki/UsersWikiSimplifyPreserveTopology > > >> >> >> A. >> >> >> Il 18 agosto 2015 13:55, G. Allegri <[hidden email]> ha scritto: >> > Sicuro, questi meccanismi, volendo anche semiautomatici (segmentazione >> > basata sull'errore della trasformazione) devono mantenere la correttezza >> > topologica. Ovvio che su una struttura topologica questo viene da sé, >> > altrimenti servono meccanismi più sofisticati, come nella >> > semplificazione >> > con preservamento della topologia. >> > >> > giovanni >> > >> > Il 18/ago/2015 13:32, "Andrea Peri" <[hidden email]> ha scritto: >> >> >> >> Pero' non va fatto in automatico, deve essere una azione voluta e >> >> ponderata. >> >> Infatti la segmentize rishcia di rompere la eventuale precisione >> >> topologica del dato. >> >> >> >> Infatti, quando si va a segmentizzare per distanza, ogni linea viene >> >> segmentizzata autonomamente. >> >> Questo potrebbe comportare che i vertici di due linee sovrapposte che >> >> in partenza erano perfettamente coincidenti, poi non lo sono piu', >> >> perche' in una linea e nell'altra si sono aggiunti vertici in punti >> >> differenti. >> >> >> >> Questo e' quasi sicuro se le due linee sono percorse in senso opposto. >> >> e questo succede sicuramente se le due linee sono coincidenti e >> >> appartenenti a due poligoni confinanti. >> >> >> >> Ecco che si entra subito in un discorso di topologia. >> >> Un conto e' fare queste cose in un mondo topologico (in una vera >> >> struttura topologica) e un conto e' farle in un mondo simple-feature, >> >> dove appena tocchi qualcosa rompi degli equilibri fragilissimi. >> >> >> >> A. >> >> >> >> >> >> Il 18 agosto 2015 13:14, <[hidden email]> ha scritto: >> >> > On Tue, 18 Aug 2015 12:41:47 +0200, G. Allegri wrote: >> >> >> >> >> >> E' proprio quello che intendevo ;) >> >> >> >> >> >> Il 18/ago/2015 12:24, "Andrea Peri" ha scritto: >> >> >> >> >> >>> Per spiegare meglio: >> >> >>> >> >> >>> il buon vecchio arcims della esri (prodotto ormai dismesso da >> >> >>> tempo) , >> >> >>> aveva un parametro che se attivato , quando trasformava da una >> >> >>> linea >> >> >>> in un altro sistema di riferimento a un altro, non si limitava a >> >> >>> trasformare i vertici, ma densificava la linea, mettendo un certo >> >> >>> numero di vertici extra. >> >> >>> Questo per permettere appunto a una linea retta di diventare >> >> >>> "curva". >> >> >>> Ovviamente era piu' lento, e anche produceva roba piu' pesante >> >> >>> visto che aveva piu' vertici, ma con ragione. >> >> >>> >> >> > >> >> > ossia, in termini Spatial SQL (vale tanto per postgis come per >> >> > splite): >> >> > per ottenere un effetto assolutamente identico basta semplicemente >> >> > richiamare la funzione ST_Segmentize() immediatamente prima di >> >> > applicare la trasformazione affine. >> >> > >> >> > ST_Segmentize(geom, max_segment_length) >> >> > >> >> > la Segmentize ritorna una nuova geometria ottenuta trasformando >> >> > tutti i Linestring o Polygon ricevuti in input in modo tale da >> >> > "spezzare" ciascun singolo segmento in una sequenza di segmentini >> >> > piu' corti, ciascuno dei quali e' individualmente non piu' lungo >> >> > della soglia prefissata dall'argomento <max_segment_length>. >> >> > e quindi in ultima analisi consente di densificare a piacere >> >> > le geometrie da sottoporre a trasformazione. >> >> > >> >> > ciao Sandro >> >> >> >> >> >> >> >> -- >> >> ----------------- >> >> Andrea Peri >> >> . . . . . . . . . >> >> qwerty àèìòù >> >> ----------------- >> >> >> >> -- >> ----------------- >> Andrea Peri >> . . . . . . . . . >> qwerty àèìòù >> ----------------- > > > > > -- > Giovanni Allegri > http://about.me/giovanniallegri > Gis3W - http://gis3w.it > Ikare - http://ikare.it > Twitter: https://twitter.com/_giohappy_ > blog: http://blog.spaziogis.it > GEO+ geomatica in Italia http://bit.ly/GEOplus -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [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. 750 iscritti al 18.3.2015 |
Non perdiamo il filo. Sto dicendo che la preserve topology funziona in una multipart, quindi in un certo senso tra geometrie distinte anche se facenti parti dello stesso elemento (multiline o multipolygon). Io l'ho usato abbondantemente in passato e ti assicuro che funziona. Provo a non usarla e vedi che belle schifezze che vengono con una simplify normale. Tornando al discorso originale, dicevo solo che serve un meccanismo simile (da vedere come potrebbe essere riprodotto, e da usare su elementi diversi) che permetta di eseguire la trasformazione mantenendo i rapporti topoloigoc-spaziali invariati. Un approccio molto banale potrebbe essere l'impiego di una griglia, con dimensioni della cella ottenute a partire all'errore della trasformazione, sulla cui base verrebbero aggiunti i vertici intermedi alle geometrie (geometrie adiacenti si ritroverebbero vertici aggiuntivi nella stessa posizione), per poi applicare la trasformazione. Il giorno 18 agosto 2015 14:30, Andrea Peri <[hidden email]> ha scritto: Non so se in una multiparte viene preservata. Giovanni Allegri http://about.me/giovanniallegri Gis3W - http://gis3w.it _______________________________________________ [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. 750 iscritti al 18.3.2015 |
Penso che convenga delimitare il problema.
Infatti il problema della segmentiazzione che rovina la topologia vale per dataset poligonali. Penso che non valga per quelli lineari e corretti topologicamente. Quindi, nel caso dei poligoni: Una possibile soluzione potrebbe essere prendere le linee di bordo, rimuovere le linee sovrapposte , segmentizzare quelle, convertire in altro sistema di riferimento e poi ricostruire nuovamente i poligoni. L'approccio della griglia non sono sicuro che possa funzionare Il problema e' che nelle simplefeautre ci sono due linee che dovrebbero essere perfettamente uguali che vengono necessariamente percorse in sensi opposti. Per cui a seconde del verso in cui viene percorso l'approssimazione del nuovo vertice aggiunto potrebbe fare scattare il vertice su una cella oppure su quella accanto. A. Il 18 agosto 2015 14:36, G. Allegri <[hidden email]> ha scritto: > Non perdiamo il filo. > Sto dicendo che la preserve topology funziona in una multipart, quindi in un > certo senso tra geometrie distinte anche se facenti parti dello stesso > elemento (multiline o multipolygon). > Io l'ho usato abbondantemente in passato e ti assicuro che funziona. Provo a > non usarla e vedi che belle schifezze che vengono con una simplify normale. > > Tornando al discorso originale, dicevo solo che serve un meccanismo simile > (da vedere come potrebbe essere riprodotto, e da usare su elementi diversi) > che permetta di eseguire la trasformazione mantenendo i rapporti > topoloigoc-spaziali invariati. > Un approccio molto banale potrebbe essere l'impiego di una griglia, con > dimensioni della cella ottenute a partire all'errore della trasformazione, > sulla cui base verrebbero aggiunti i vertici intermedi alle geometrie > (geometrie adiacenti si ritroverebbero vertici aggiuntivi nella stessa > posizione), per poi applicare la trasformazione. > > > > Il giorno 18 agosto 2015 14:30, Andrea Peri <[hidden email]> ha > scritto: >> >> Non so se in una multiparte viene preservata. >> Non ci conterei troppo. >> >> Ma comunque il problema e' tra oggetti distinti. >> La preservazione internamente a un oggetto (e un oggetto multiparte, >> cioe' coposto di 2 o piu'parti e' comunque un unico oggetto) e' meno >> del minimo. >> >> Un qualsiasi poligono anche il piu' fetido preso da solo se non ha >> invalidita' geometriche e' implicitamente topologico. >> La topologia e' una caratteristica che connota le relazioni tra >> oggetti distinti e diversi. E quindi non ha senso guardarla >> internamente a un singolo oggetto. >> >> A. >> >> >> >> Il 18 agosto 2015 14:24, G. Allegri <[hidden email]> ha scritto: >> >> No, la semplificazione con preservamento della topologia preserva solo >> >> la posizione dei nodi. >> >> >> >> Non nei vertici intermedi. >> >> Per cui la topologia e' comunque rovinata. >> > >> > >> > ??? >> > Tra oggetti distinti ok, ma in una multipart viene preservata, come no? >> > https://trac.osgeo.org/postgis/wiki/UsersWikiSimplifyPreserveTopology >> > >> > >> >> >> >> >> >> A. >> >> >> >> >> >> Il 18 agosto 2015 13:55, G. Allegri <[hidden email]> ha scritto: >> >> > Sicuro, questi meccanismi, volendo anche semiautomatici >> >> > (segmentazione >> >> > basata sull'errore della trasformazione) devono mantenere la >> >> > correttezza >> >> > topologica. Ovvio che su una struttura topologica questo viene da sé, >> >> > altrimenti servono meccanismi più sofisticati, come nella >> >> > semplificazione >> >> > con preservamento della topologia. >> >> > >> >> > giovanni >> >> > >> >> > Il 18/ago/2015 13:32, "Andrea Peri" <[hidden email]> ha scritto: >> >> >> >> >> >> Pero' non va fatto in automatico, deve essere una azione voluta e >> >> >> ponderata. >> >> >> Infatti la segmentize rishcia di rompere la eventuale precisione >> >> >> topologica del dato. >> >> >> >> >> >> Infatti, quando si va a segmentizzare per distanza, ogni linea viene >> >> >> segmentizzata autonomamente. >> >> >> Questo potrebbe comportare che i vertici di due linee sovrapposte >> >> >> che >> >> >> in partenza erano perfettamente coincidenti, poi non lo sono piu', >> >> >> perche' in una linea e nell'altra si sono aggiunti vertici in punti >> >> >> differenti. >> >> >> >> >> >> Questo e' quasi sicuro se le due linee sono percorse in senso >> >> >> opposto. >> >> >> e questo succede sicuramente se le due linee sono coincidenti e >> >> >> appartenenti a due poligoni confinanti. >> >> >> >> >> >> Ecco che si entra subito in un discorso di topologia. >> >> >> Un conto e' fare queste cose in un mondo topologico (in una vera >> >> >> struttura topologica) e un conto e' farle in un mondo >> >> >> simple-feature, >> >> >> dove appena tocchi qualcosa rompi degli equilibri fragilissimi. >> >> >> >> >> >> A. >> >> >> >> >> >> >> >> >> Il 18 agosto 2015 13:14, <[hidden email]> ha scritto: >> >> >> > On Tue, 18 Aug 2015 12:41:47 +0200, G. Allegri wrote: >> >> >> >> >> >> >> >> E' proprio quello che intendevo ;) >> >> >> >> >> >> >> >> Il 18/ago/2015 12:24, "Andrea Peri" ha scritto: >> >> >> >> >> >> >> >>> Per spiegare meglio: >> >> >> >>> >> >> >> >>> il buon vecchio arcims della esri (prodotto ormai dismesso da >> >> >> >>> tempo) , >> >> >> >>> aveva un parametro che se attivato , quando trasformava da una >> >> >> >>> linea >> >> >> >>> in un altro sistema di riferimento a un altro, non si limitava a >> >> >> >>> trasformare i vertici, ma densificava la linea, mettendo un >> >> >> >>> certo >> >> >> >>> numero di vertici extra. >> >> >> >>> Questo per permettere appunto a una linea retta di diventare >> >> >> >>> "curva". >> >> >> >>> Ovviamente era piu' lento, e anche produceva roba piu' pesante >> >> >> >>> visto che aveva piu' vertici, ma con ragione. >> >> >> >>> >> >> >> > >> >> >> > ossia, in termini Spatial SQL (vale tanto per postgis come per >> >> >> > splite): >> >> >> > per ottenere un effetto assolutamente identico basta semplicemente >> >> >> > richiamare la funzione ST_Segmentize() immediatamente prima di >> >> >> > applicare la trasformazione affine. >> >> >> > >> >> >> > ST_Segmentize(geom, max_segment_length) >> >> >> > >> >> >> > la Segmentize ritorna una nuova geometria ottenuta trasformando >> >> >> > tutti i Linestring o Polygon ricevuti in input in modo tale da >> >> >> > "spezzare" ciascun singolo segmento in una sequenza di segmentini >> >> >> > piu' corti, ciascuno dei quali e' individualmente non piu' lungo >> >> >> > della soglia prefissata dall'argomento <max_segment_length>. >> >> >> > e quindi in ultima analisi consente di densificare a piacere >> >> >> > le geometrie da sottoporre a trasformazione. >> >> >> > >> >> >> > ciao Sandro >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> ----------------- >> >> >> Andrea Peri >> >> >> . . . . . . . . . >> >> >> qwerty àèìòù >> >> >> ----------------- >> >> >> >> >> >> >> >> -- >> >> ----------------- >> >> Andrea Peri >> >> . . . . . . . . . >> >> qwerty àèìòù >> >> ----------------- >> > >> > >> > >> > >> > -- >> > Giovanni Allegri >> > http://about.me/giovanniallegri >> > Gis3W - http://gis3w.it >> > Ikare - http://ikare.it >> > Twitter: https://twitter.com/_giohappy_ >> > blog: http://blog.spaziogis.it >> > GEO+ geomatica in Italia http://bit.ly/GEOplus >> >> >> >> -- >> ----------------- >> Andrea Peri >> . . . . . . . . . >> qwerty àèìòù >> ----------------- > > > > > -- > Giovanni Allegri > http://about.me/giovanniallegri > Gis3W - http://gis3w.it > Ikare - http://ikare.it > Twitter: https://twitter.com/_giohappy_ > blog: http://blog.spaziogis.it > GEO+ geomatica in Italia http://bit.ly/GEOplus -- ----------------- Andrea Peri . . . . . . . . . qwerty àèìòù ----------------- _______________________________________________ [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. 750 iscritti al 18.3.2015 |
In reply to this post by Amedeo Fadini
Il giorno Tue, 18 Aug 2015 11:43:30 +0200
Amedeo Fadini <[hidden email]> ha scritto: ciao Amedeo, > 2015-08-18 11:31 GMT+02:00 <[hidden email]>: > > > ciao Strk, > > > viceversa tutta questa parte "di supporto" e' totalmente assente in > > PostGIS, che da per scontato che la matrice di trasformazione affine > > sia gia' nota a priori. > > Ecco una cosa interessante da aggiugere in postgis... > Quanto costerebbe? Chi mi fa un preventivo? a parte le molteplici fonti che potrai trovare in rete o in testi di algebra lineare (ad es. nel link che ho passato tempo fa in lista) ne trovi una versione rozza (python, non pgsql) nella mia prima versione del plugin VectGeoRef(*); dovrei averne una versione forse più pulita per un'altra idea su GPS/rPI/etc: se ti interessa ne parliamo in pvt (**); > amefad ciao, giuliano (*) non so se e come modificata da Daniele S. nella nuova versione VectorRectify, forse la parte è cassata perchè il nuovo plugin si appoggia alla logica interna dello script di Grass; (**) preventivo/costo: un caffè a Lecco :-) _______________________________________________ [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. 750 iscritti al 18.3.2015 |
Free forum by Nabble | Edit this page |