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)
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).
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) ?
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
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) ?
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.
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?
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…
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) ?
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.
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.
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) ?
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.
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 <aperi2007@gmail.com> 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.
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…
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) ?
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.
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 <aperi2007@gmail.com> 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" <giohappy@gmail.com> 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, <a.furieri@lqt.it> 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)
?
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
_______________________________________________
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.
750 iscritti al 18.3.2015
_______________________________________________
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.
750 iscritti al 18.3.2015
--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
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.
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.
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…
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)
?
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.
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.
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, <a.furieri@lqt.it> 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 àèìòù
-----------------
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.
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.
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.
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 <giohappy@gmail.com> 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" <aperi2007@gmail.com> 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, <a.furieri@lqt.it> 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 àèìòù
-----------------
Il 18 agosto 2015 13:55, G. Allegri <giohappy@gmail.com> 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" <aperi2007@gmail.com> 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, <a.furieri@lqt.it> 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 àèìòù
-----------------
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 <giohappy@gmail.com> 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.
Il 18 agosto 2015 13:55, G. Allegri <giohappy@gmail.com> 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" <aperi2007@gmail.com> 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, <a.furieri@lqt.it> 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 àèìòù
-----------------
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 <aperi2007@gmail.com> 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.
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.
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.
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.
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 <giohappy@gmail.com> 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 <aperi2007@gmail.com> 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 <giohappy@gmail.com> 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 <giohappy@gmail.com> 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" <aperi2007@gmail.com> 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, <a.furieri@lqt.it> 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 àèìòù
-----------------
Il giorno Tue, 18 Aug 2015 11:43:30 +0200
Amedeo Fadini <amefad@gmail.com> ha scritto:
ciao Amedeo,
2015-08-18 11:31 GMT+02:00 <a.furieri@lqt.it>:
> 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;
