Trasformazione per punti omologhi in PostGIS

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Trasformazione per punti omologhi in PostGIS

PietroR3
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) ?

Pietro




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
Reply | Threaded
Open this post in threaded view
|

Re: Trasformazione per punti omologhi in PostGIS

a.furieri
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
Reply | Threaded
Open this post in threaded view
|

Re: Trasformazione per punti omologhi in PostGIS

Sandro Santilli
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
Reply | Threaded
Open this post in threaded view
|

Re: Trasformazione per punti omologhi in PostGIS

Amedeo Fadini
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
Reply | Threaded
Open this post in threaded view
|

Re: Trasformazione per punti omologhi in PostGIS

a.furieri
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
Reply | Threaded
Open this post in threaded view
|

Re: Trasformazione per punti omologhi in PostGIS

Amedeo Fadini
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
Reply | Threaded
Open this post in threaded view
|

Re: Trasformazione per punti omologhi in PostGIS

giohappy
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:
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



--

_______________________________________________
[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
Reply | Threaded
Open this post in threaded view
|

Re: Trasformazione per punti omologhi in PostGIS

Andrea Peri

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



--

_______________________________________________
[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

_______________________________________________
[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
Reply | Threaded
Open this post in threaded view
|

Re: Trasformazione per punti omologhi in PostGIS

giohappy
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:

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



--

_______________________________________________
[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



--

_______________________________________________
[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
Reply | Threaded
Open this post in threaded view
|

Re: Trasformazione per punti omologhi in PostGIS

Andrea Peri
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
Reply | Threaded
Open this post in threaded view
|

Re: Trasformazione per punti omologhi in PostGIS

giohappy

E' proprio quello che intendevo ;)

Il 18/ago/2015 12:24, "Andrea Peri" <[hidden email]> 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.

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
Reply | Threaded
Open this post in threaded view
|

Re: Trasformazione per punti omologhi in PostGIS

a.furieri
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
Reply | Threaded
Open this post in threaded view
|

Re: Trasformazione per punti omologhi in PostGIS

Andrea Peri
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
Reply | Threaded
Open this post in threaded view
|

Re: Trasformazione per punti omologhi in PostGIS

giohappy

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 àèìòù
-----------------

_______________________________________________
[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
Reply | Threaded
Open this post in threaded view
|

Re: Trasformazione per punti omologhi in PostGIS

Andrea Peri
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
Reply | Threaded
Open this post in threaded view
|

Re: Trasformazione per punti omologhi in PostGIS

giohappy
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?

 

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
Reply | Threaded
Open this post in threaded view
|

Re: Trasformazione per punti omologhi in PostGIS

Andrea Peri
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
Reply | Threaded
Open this post in threaded view
|

Re: Trasformazione per punti omologhi in PostGIS

giohappy
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 àèìòù
-----------------



--

_______________________________________________
[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
Reply | Threaded
Open this post in threaded view
|

Re: Trasformazione per punti omologhi in PostGIS

Andrea Peri
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
Reply | Threaded
Open this post in threaded view
|

Re: Trasformazione per punti omologhi in PostGIS

Giuliano Curti
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
12