affine transformation parametri

[Ely Parker]

Scusate conoscete qualche tool,  che dati due punti a e b  e le loro
coordinate in un layer mi permette di calcolare i parametri del plugin
affine transformation per posizione per esempio il vertine di unfeatures
situata in a esattamente in b?

_______________________________________________
[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.
807 iscritti al 31/03/2016

[a.furieri]

On Tue, 14 Feb 2017 17:39:48 +0100, Ely Parker wrote:
> Scusate conoscete qualche tool,  che dati due punti a e b  e le loro
> coordinate in un layer mi permette di calcolare i parametri del
> plugin
> affine transformation per posizione per esempio il vertine di
> unfeatures situata in a esattamente in b?
>

SpatiaLite a partire dalla versione 4.3 supporta la funzione
GCP_Compute() che fa esattamente quel che chiedi.
accetta in input delle coppie di punti corrispondenti (il
primo nel sistema di riferimento noto, il secondo in quello
ignoto) e su questa base si calcola i coefficienti della
matrice di trasformazione affine.
puoi anche scegliere tra diversi algoritmi:
- RMSE (minimi quadrati) del primo, secondo o terzo ordine.
- TSP (Thin Plate Spline)

nota bene: per potere calcolare i coefficienti della matrice
di trasformazione affine servono _almeno_ tre coppie di punti;
in genere per potere sperare di ottenere risultati decenti se
ne usano molti di piu' (decine o meglio ancora centinaia).

se sei interessato ad approfondire:
https://www.gaia-gis.it/fossil/libspatialite/wiki?name=Ground+Control+Points

in alternativa potresti usare il metodo v.rectify di Grass GIS;
SpatiaLite usa esattamente il medesimo codice di Grass, per cui
l'una o l'altro si equivalgono.
se ti trovi piu' a tuo agio con SQL usa SpatiaLite, altrimenti
usa Grass GIS.

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.
807 iscritti al 31/03/2016

[Ely Parker]

qualcosa che funzioni con qgis?e qon il plugin qgis affine

ho trovato una documentazione che richiama alla soluzione di una matrice
e spiega come usare risolutore di equazione online, come spiegato in
questo video
https://www.youtube.com/watch?v=cwxmrEAc1Dw

ma onestamente non mi ha funzionato

qualcuno ha mai usato questo plugin? e mi sa dire l'affidabilità?

ho provato anche il plugin move di fabio saccon ma per quanto si
avvicini al risultato per qualche motivo i punti non si sovrappongono

un altro problema che si pone con il plugin move e qgis è se c'è la
possibilità di spostare le feature di piu livelli secondo lo spostamento
nel layer su cui ho usato i move, chiedo a chi è piu esperto di me c'è
un modo per farlo ossia di agganciare le feature di un livello con un
altro in maniera che eventualmente  si spostino allo stesso  modo

esempio pratico per capirci catastali su cui si vuole perferzionare la
sovrapposizione sulle ortofoto dei layer fabbricati e  particelle,
magari spostandoli manualmente, cosa si potrebbe fare?



Il 14/02/2017 18:15, [hidden email] ha scritto:

> On Tue, 14 Feb 2017 17:39:48 +0100, Ely Parker wrote:
>> Scusate conoscete qualche tool,  che dati due punti a e b  e le loro
>> coordinate in un layer mi permette di calcolare i parametri del plugin
>> affine transformation per posizione per esempio il vertine di
>> unfeatures situata in a esattamente in b?
>>
>
> SpatiaLite a partire dalla versione 4.3 supporta la funzione
> GCP_Compute() che fa esattamente quel che chiedi.
> accetta in input delle coppie di punti corrispondenti (il
> primo nel sistema di riferimento noto, il secondo in quello
> ignoto) e su questa base si calcola i coefficienti della
> matrice di trasformazione affine.
> puoi anche scegliere tra diversi algoritmi:
> - RMSE (minimi quadrati) del primo, secondo o terzo ordine.
> - TSP (Thin Plate Spline)
>
> nota bene: per potere calcolare i coefficienti della matrice
> di trasformazione affine servono _almeno_ tre coppie di punti;
> in genere per potere sperare di ottenere risultati decenti se
> ne usano molti di piu' (decine o meglio ancora centinaia).
>
> se sei interessato ad approfondire:
> https://www.gaia-gis.it/fossil/libspatialite/wiki?name=Ground+Control+Points 
>
>
> in alternativa potresti usare il metodo v.rectify di Grass GIS;
> SpatiaLite usa esattamente il medesimo codice di Grass, per cui
> l'una o l'altro si equivalgono.
> se ti trovi piu' a tuo agio con SQL usa SpatiaLite, altrimenti
> usa Grass GIS.
>
> 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.
> 807 iscritti al 31/03/2016

_______________________________________________
[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.
807 iscritti al 31/03/2016

[giohappy]

Non ho mai testato il plugin vectoGeoref, ma dovrebbe permettere di
inserire visualmente i punti doppi. Dal codice mi pare però di capire che
fa solo trasformazioni lineari (non polinomiali). https://plugins.qgis.org/
plugins/vectGeoref/

Altra strada è passare i punti doppi a ogr2ogr con l'opzione -gcp:
http://www.gdal.org

Comunque secondo me la strada più semplice e robusta è tramite Spatialite,
come indicato da Sandro.

Giovanni


Il 14 feb 2017 20:03, "Ely Parker" <[hidden email]> ha scritto:

> qualcosa che funzioni con qgis?e qon il plugin qgis affine
>
> ho trovato una documentazione che richiama alla soluzione di una matrice e
> spiega come usare risolutore di equazione online, come spiegato in questo
> video
> https://www.youtube.com/watch?v=cwxmrEAc1Dw
>
> ma onestamente non mi ha funzionato
>
> qualcuno ha mai usato questo plugin? e mi sa dire l'affidabilità?
>
> ho provato anche il plugin move di fabio saccon ma per quanto si avvicini
> al risultato per qualche motivo i punti non si sovrappongono
>
> un altro problema che si pone con il plugin move e qgis è se c'è la
> possibilità di spostare le feature di piu livelli secondo lo spostamento
> nel layer su cui ho usato i move, chiedo a chi è piu esperto di me c'è un
> modo per farlo ossia di agganciare le feature di un livello con un altro in
> maniera che eventualmente  si spostino allo stesso  modo
>
> esempio pratico per capirci catastali su cui si vuole perferzionare la
> sovrapposizione sulle ortofoto dei layer fabbricati e  particelle, magari
> spostandoli manualmente, cosa si potrebbe fare?
>
>
>
> Il 14/02/2017 18:15, [hidden email] ha scritto:
>
>> On Tue, 14 Feb 2017 17:39:48 +0100, Ely Parker wrote:
>>
>>> Scusate conoscete qualche tool,  che dati due punti a e b  e le loro
>>> coordinate in un layer mi permette di calcolare i parametri del plugin
>>> affine transformation per posizione per esempio il vertine di
>>> unfeatures situata in a esattamente in b?
>>>
>>>
>> SpatiaLite a partire dalla versione 4.3 supporta la funzione
>> GCP_Compute() che fa esattamente quel che chiedi.
>> accetta in input delle coppie di punti corrispondenti (il
>> primo nel sistema di riferimento noto, il secondo in quello
>> ignoto) e su questa base si calcola i coefficienti della
>> matrice di trasformazione affine.
>> puoi anche scegliere tra diversi algoritmi:
>> - RMSE (minimi quadrati) del primo, secondo o terzo ordine.
>> - TSP (Thin Plate Spline)
>>
>> nota bene: per potere calcolare i coefficienti della matrice
>> di trasformazione affine servono _almeno_ tre coppie di punti;
>> in genere per potere sperare di ottenere risultati decenti se
>> ne usano molti di piu' (decine o meglio ancora centinaia).
>>
>> se sei interessato ad approfondire:
>> https://www.gaia-gis.it/fossil/libspatialite/wiki?name=
>> Ground+Control+Points
>>
>> in alternativa potresti usare il metodo v.rectify di Grass GIS;
>> SpatiaLite usa esattamente il medesimo codice di Grass, per cui
>> l'una o l'altro si equivalgono.
>> se ti trovi piu' a tuo agio con SQL usa SpatiaLite, altrimenti
>> usa Grass GIS.
>>
>> 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.
>> 807 iscritti al 31/03/2016
>>
>
>
> _______________________________________________
> [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.
> 807 iscritti al 31/03/2016

_______________________________________________
[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.
807 iscritti al 31/03/2016

[Giuliano Curti]

On 2/14/17, G. Allegri <[hidden email]> wrote:
> Non ho mai testato il plugin vectoGeoref, ma dovrebbe permettere di
> inserire visualmente i punti doppi. Dal codice mi pare però di capire che
> fa solo trasformazioni lineari (non polinomiali). https://plugins.qgis.org/
> plugins/vectGeoref/

ciao Giovanni, Alessandro, Ely e a tutti;

sono l'autore (con altri) del plugin vectorGeoref ed è un piacere
scambiare quattro chiacchere sull'argomento; oltre a quanto detto da
Alessandro F. che costituisce la bibbia, ed a quanto ha correttamente
detto Giovanni A., posso solo aggiungere:

a) effettivamente il plugin vectorGeoref esegue la sola trasformazione lineare;

b) il numero minimo di (coppie di) punti per una trasformazione sono 3
(condizione che dà luogo ad una trasformazione esatta), ma:

b1) si possono ovviamente inserire più di 3 coppie nel qual caso la
trasformazione consente la soluzione che offre il minor errore
quadratico (LSM);

c) si potrebbe anche consentire la trasformazione con due (coppie di)
punti con queste declinazioni:

c1 traslazione sul primo punto e rotazione per allineare sul secondo
(senza scalatura)

c2) traslazione con scalatura isotropa per allineare i due punti;

d) se può essere utile ho una versione seprimentale che gestisce le
attendibilità degli accoppiamenti, cioè si può dare un peso alle varie
coppie di punti (un pò quello che viene fatto nelle trasformazioni
catastali anche se non conosco i pesi effettivi attribuiti alle varie
attendibilità dei PF);

d) purtroppo non conosco e non ho ancora avuto modo di approfondire le
TSP (ma potrebbe essere la volta buona);

tutto ciò deriva da un divertente studio di algebra lineare di qualche
tempo fa di cui sono al momento un pò a digiuno, però gli elementi che
ho sono disponibili per tutti e, se utile, posso rinfrescare qualche
conoscenza adesso assopita :-)

grazie, ciao,
giuliano
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
807 iscritti al 31/03/2016

[a.furieri]

On Tue, 14 Feb 2017 22:54:01 +0100, Giuliano Curti wrote:

> sono l'autore (con altri) del plugin vectorGeoref ed è un piacere
> scambiare quattro chiacchere sull'argomento;
>
> a) effettivamente il plugin vectorGeoref esegue la sola
> trasformazione lineare;
>
> d) purtroppo non conosco e non ho ancora avuto modo di approfondire
> le
> TSP (ma potrebbe essere la volta buona);
>
> tutto ciò deriva da un divertente studio di algebra lineare di
> qualche
> tempo fa di cui sono al momento un pò a digiuno, però gli elementi
> che
> ho sono disponibili per tutti e, se utile, posso rinfrescare qualche
> conoscenza adesso assopita :-)
>

Giuliano,

il codice di Grass GIS offre gia' un'ottima implementazione
basata sugli algoritmi RMSE e TSP.
e per nostra fortuna e' scritto interamente in puro C (del
tutto privo di barocchismi rococo' alla C++), e' molto
lineare e non richiede nessuna dipendenza esterna; e'
facilmente portabile su qualsiasi piattaforma e si integra
molto facilmente in altri contesti (anche C++).

quando l'ho riciclato all'interno di SpatiaLite in
pratica ho dovuto semplicemente scrivere un piccolo
modulo a monte che gestisce il passaggio degli argomenti
ed un secondo modulo altrettanto piccolo a valle per
recuperare i risultati; nulla di complicato.

dato che Grass GIS e' rilasciato con licenza GPL non
esistono problemi legali di sorta; puoi liberamente
riciclare tuttti i sorgenti che ti servono anche
eventualmente modificandoli e riadattandoli ai tuoi
scopi particolari.
basta solo che anche il prodotto derivato continui
ad essere rilasciato sotto GPL

personalmente penso che se tu riuscissi ad integrare
il codice di Grass dentro al tuo plugin vectortGeoref
sarebbe decisamente un'ottima iniziativa.
non solo espanderesti le capacita' del tuo plugin, ma
inoltre otterremmo anche che Grass, SpatiaLite e
QGIS fornirebbero risultati analoghi visto che si
baserebbero esattamente sul medesimo codice.
e' un caso da manuale di riuso e condivisione
intelligente del sw libero open source.

se sei in qualche modo interessato posso fornirti
(anche in privato) alcuni suggerimenti utili che
derivano dalla mia esperienza di prima mano
maturata quando ho sviluppato il modulo GCP per
SpatiaLite.

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.
807 iscritti al 31/03/2016

[giohappy]

Sarei curioso di vedere se il codice delle GDAL (guarda caso anch'esso
prevede polinomiali fino al 3° e TSP) ha qualcosa in comune con quello di
GRASS GIS.

Il problema principale, Sandro, è che vectorGeoreg è Python. Però potrebbe
essere un nell'esercizio, neanche troppo complicato, di binding Python/C.
Ci sarebbe però il problema della portabilità multipiattaforna... Il plugin
dovrebbe portarsi dietro le librerie del pezzo nativo per tutti gli OS
(.dll, .so, ecc.)

Giovanni

Il 15 feb 2017 09:05, <[hidden email]> ha scritto:

> On Tue, 14 Feb 2017 22:54:01 +0100, Giuliano Curti wrote:
>
>> sono l'autore (con altri) del plugin vectorGeoref ed è un piacere
>> scambiare quattro chiacchere sull'argomento;
>>
>> a) effettivamente il plugin vectorGeoref esegue la sola
>> trasformazione lineare;
>>
>> d) purtroppo non conosco e non ho ancora avuto modo di approfondire le
>> TSP (ma potrebbe essere la volta buona);
>>
>> tutto ciò deriva da un divertente studio di algebra lineare di qualche
>> tempo fa di cui sono al momento un pò a digiuno, però gli elementi che
>> ho sono disponibili per tutti e, se utile, posso rinfrescare qualche
>> conoscenza adesso assopita :-)
>>
>>
> Giuliano,
>
> il codice di Grass GIS offre gia' un'ottima implementazione
> basata sugli algoritmi RMSE e TSP.
> e per nostra fortuna e' scritto interamente in puro C (del
> tutto privo di barocchismi rococo' alla C++), e' molto
> lineare e non richiede nessuna dipendenza esterna; e'
> facilmente portabile su qualsiasi piattaforma e si integra
> molto facilmente in altri contesti (anche C++).
>
> quando l'ho riciclato all'interno di SpatiaLite in
> pratica ho dovuto semplicemente scrivere un piccolo
> modulo a monte che gestisce il passaggio degli argomenti
> ed un secondo modulo altrettanto piccolo a valle per
> recuperare i risultati; nulla di complicato.
>
> dato che Grass GIS e' rilasciato con licenza GPL non
> esistono problemi legali di sorta; puoi liberamente
> riciclare tuttti i sorgenti che ti servono anche
> eventualmente modificandoli e riadattandoli ai tuoi
> scopi particolari.
> basta solo che anche il prodotto derivato continui
> ad essere rilasciato sotto GPL
>
> personalmente penso che se tu riuscissi ad integrare
> il codice di Grass dentro al tuo plugin vectortGeoref
> sarebbe decisamente un'ottima iniziativa.
> non solo espanderesti le capacita' del tuo plugin, ma
> inoltre otterremmo anche che Grass, SpatiaLite e
> QGIS fornirebbero risultati analoghi visto che si
> baserebbero esattamente sul medesimo codice.
> e' un caso da manuale di riuso e condivisione
> intelligente del sw libero open source.
>
> se sei in qualche modo interessato posso fornirti
> (anche in privato) alcuni suggerimenti utili che
> derivano dalla mia esperienza di prima mano
> maturata quando ho sviluppato il modulo GCP per
> SpatiaLite.
>
> 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.
> 807 iscritti al 31/03/2016

_______________________________________________
[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.
807 iscritti al 31/03/2016

[a.furieri]

On Wed, 15 Feb 2017 09:17:25 +0100, G. Allegri wrote:
> Sarei curioso di vedere se il codice delle GDAL (guarda caso
> anch'esso
> prevede polinomiali fino al 3° e TSP) ha qualcosa in comune con
> quello di GRASS GIS.
>

per quanto sono riuscito a ricostruire quando me ne sono
occupato all'epoca (grazie a contatti diretti con Markus
Neteler di Grass GIS e con Even Rouault di GDAL) le due
implementazioni nascono dalla medesima radice, ma poi
hanno avuto evoluzioni distinte e separate per cui ad
oggi sono significativamente differenti.
In soldoni, quella di Grass e' molto piu' avanzata
di quella di GDAL.

- GDAL usa ancora oggi il vecchio codice inizialmente
   adottato da Grass GIS
- in anni molto recenti l'implementazione di Grass e'
   stata completamente riscritta da Markus Metz, e
   sicuramente ora e' decisamente migliore della
   precedente (meno bugs, piu' veloce etc)
- ma GDAL non puo' assolutamente incorporare tutte
   queste ultime migliorie per conflitto di licenze:
   GDAL adotta la X/MIT che non e' compatibile con
   la GPL di Grass GIS.
   ergo GDAL deve necessariamente continuare con la
   vecchissima versione rilasciata molti anni fa quando
   Grass non aveva ancora adottato la GPL.


> Il problema principale, Sandro, è che vectorGeoreg è Python.
>

ahi ahi ahi ... allora prevedo grossi mal di testa :-D

> Però
> potrebbe essere un nell'esercizio, neanche troppo complicato, di
> binding Python/C. Ci sarebbe però il problema della portabilità
> multipiattaforna... Il plugin dovrebbe portarsi dietro le librerie
> del
> pezzo nativo per tutti gli OS (.dll, .so, ecc.)
>

no, in questi termini l'operazione ha poco senso; come
dici tu, dovendo passandro per Python ci andiamo ad infilare
a capofitto in un bel groviglio di vipere.

peccato, perche' invece in puro C/C++ l'operazione di
potrebbe fare con poco sforzo e senza complicazioni
di sorta, visto che basterebbe semplicemente incorporare
il codice derivato da Grass all'interno del sorgente
del plugin senza doversi tirare dietro nessuna
ulteriore dipendenza.
giusto per curiosita': ma QGIS non supporta i plugin
scritti in C++ ?
mi pareva di ricordare di si, ma magari nel frattempo
le cose sono cambiate.

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.
807 iscritti al 31/03/2016

[geodrinx]

Buongiorno,

voglio solo dare un punto di riflessione sull'argomento "trasformazioni
affini".

Parto da una domanda:  Quale è il motivo per cui si vuole deformare il
vettoriale ?

Mi rispondo da solo:  Per visualizzare il vettoriale "correttamente
posizionato" sull'ortofoto.

Giusto ?

In questo caso faccio un'altra domanda:  Quali aspettative ci attendiamo
dal risultato vettoriale ?

Siamo consci che il vettoriale così deformato non è più un "documento
ufficiale" e che non possiamo più misurare aree distanze ed angoli da tali
vettori ?

Sappiamo che tale risultato vettoriale non è più reversibile, e che non
possiamo più tornare alla geometria di partenza, rovesciando i parametri ?

Ne siamo consapevoli ?  Allora OK.   In questo caso, suggerisco di marcare
i file risultanti con un prefisso che ci ricordi che si tratta di vettori
deformati, da utilizzare solo in visualizzazione,da cestinare il più presto
possibile, e da non diffondere.


A presto

Geo


Il giorno 15 febbraio 2017 09:17, G. Allegri <[hidden email]> ha
scritto:

> Sarei curioso di vedere se il codice delle GDAL (guarda caso anch'esso
> prevede polinomiali fino al 3° e TSP) ha qualcosa in comune con quello di
> GRASS GIS.
>
> Il problema principale, Sandro, è che vectorGeoreg è Python. Però potrebbe
> essere un nell'esercizio, neanche troppo complicato, di binding Python/C.
> Ci sarebbe però il problema della portabilità multipiattaforna... Il plugin
> dovrebbe portarsi dietro le librerie del pezzo nativo per tutti gli OS
> (.dll, .so, ecc.)
>
> Giovanni
>
> Il 15 feb 2017 09:05, <[hidden email]> ha scritto:
>
> > On Tue, 14 Feb 2017 22:54:01 +0100, Giuliano Curti wrote:
> >
> >> sono l'autore (con altri) del plugin vectorGeoref ed è un piacere
> >> scambiare quattro chiacchere sull'argomento;
> >>
> >> a) effettivamente il plugin vectorGeoref esegue la sola
> >> trasformazione lineare;
> >>
> >> d) purtroppo non conosco e non ho ancora avuto modo di approfondire le
> >> TSP (ma potrebbe essere la volta buona);
> >>
> >> tutto ciò deriva da un divertente studio di algebra lineare di qualche
> >> tempo fa di cui sono al momento un pò a digiuno, però gli elementi che
> >> ho sono disponibili per tutti e, se utile, posso rinfrescare qualche
> >> conoscenza adesso assopita :-)
> >>
> >>
> > Giuliano,
> >
> > il codice di Grass GIS offre gia' un'ottima implementazione
> > basata sugli algoritmi RMSE e TSP.
> > e per nostra fortuna e' scritto interamente in puro C (del
> > tutto privo di barocchismi rococo' alla C++), e' molto
> > lineare e non richiede nessuna dipendenza esterna; e'
> > facilmente portabile su qualsiasi piattaforma e si integra
> > molto facilmente in altri contesti (anche C++).
> >
> > quando l'ho riciclato all'interno di SpatiaLite in
> > pratica ho dovuto semplicemente scrivere un piccolo
> > modulo a monte che gestisce il passaggio degli argomenti
> > ed un secondo modulo altrettanto piccolo a valle per
> > recuperare i risultati; nulla di complicato.
> >
> > dato che Grass GIS e' rilasciato con licenza GPL non
> > esistono problemi legali di sorta; puoi liberamente
> > riciclare tuttti i sorgenti che ti servono anche
> > eventualmente modificandoli e riadattandoli ai tuoi
> > scopi particolari.
> > basta solo che anche il prodotto derivato continui
> > ad essere rilasciato sotto GPL
> >
> > personalmente penso che se tu riuscissi ad integrare
> > il codice di Grass dentro al tuo plugin vectortGeoref
> > sarebbe decisamente un'ottima iniziativa.
> > non solo espanderesti le capacita' del tuo plugin, ma
> > inoltre otterremmo anche che Grass, SpatiaLite e
> > QGIS fornirebbero risultati analoghi visto che si
> > baserebbero esattamente sul medesimo codice.
> > e' un caso da manuale di riuso e condivisione
> > intelligente del sw libero open source.
> >
> > se sei in qualche modo interessato posso fornirti
> > (anche in privato) alcuni suggerimenti utili che
> > derivano dalla mia esperienza di prima mano
> > maturata quando ho sviluppato il modulo GCP per
> > SpatiaLite.
> >
> > 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.
> > 807 iscritti al 31/03/2016
>
> _______________________________________________
> [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.
> 807 iscritti al 31/03/2016
>

_______________________________________________
[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.
807 iscritti al 31/03/2016

[Giuliano Curti]

On 2/15/17, Geo DrinX <[hidden email]> wrote:
> Buongiorno,

ciao Roberto,


> voglio solo dare un punto di riflessione sull'argomento "trasformazioni
> affini".
>
> Parto da una domanda:  Quale è il motivo per cui si vuole deformare il
> vettoriale ?
> .........
> Siamo consci che il vettoriale così deformato non è più un "documento
> ufficiale" e che non possiamo più misurare aree distanze ed angoli da tali
> vettori ?

non sono in grado di dibattere le tue asserzioni circa la
"ufficialità" degli oggetti trasformati (credo che la loro
attendibilità derivi dai processi messi in campo che in questo caso
attengono all'algebra lineare, in particolare al metodo dei minimi
quadrati messo a punto da Gauss appena dopo il 1800 e pubblicati credo
intorno al 1819);
posso invece dire qualcosa intorno alla motivazione per cui è nato
vectorGeoref, molto semplice, che ha due filoni paralleli:
a) io arrivo da esperienza cad (architetto); in questa sono abituato a
lavorare in coordinate locali, molto locali: uno spigolo del mio
progetto rappresenterà l'origine (0,0,0) indipendentemente dalla
latitudine e/o cartografia ufficiale del sito (di questo e altre
caratteristiche terrò conto nel progetto in altro modo, ma non nelle
coordinate);
però, c'è sempre un però, potrei essere di fronte alla richiesta di
georeferenziare il mio progetto; potrei anche essere di fronte a
progetti stradali e/o di arredo urbano che, finita la fase di
progettazione architettonica, vanno ricondotti alla cartografia
ufficiale;
b) ho avuto sempre molto interesse per la matematica; la pensione mi
ha consentito di applicare risorse in questa direzione e quindi ho
affrontato l'algebra lineare: la nascita del plugin è stata un pò
l'esercizio con cui verificavo i miei progressi nella materia;
c) ho detto due, ma forse c'è un terzo aspetto da considerare: esiste
un bellissimo plugin che georeferenzia i raster (in modo molto più
sofisticato del mio); avendo i problemi di cui al punto a) mi sembrava
naturale disporre di uno strumento analogo anche per i vettoriali;
quindi come vedi, tutto molto specifico e particolare; in realtà il
plugin mi è "sfuggito di mano" sollevando qualche interesse nella
comunità e si era parlato di portarlo, insieme al più maturo plugin
per i raster, all'interno del core, ma poi francamente ho perso gli
sviluppi, anche per la mia grande disabilità nella lingua inglese :-)


> Sappiamo che tale risultato vettoriale non è più reversibile, e che non
> possiamo più tornare alla geometria di partenza, rovesciando i parametri ?
>
> Ne siamo consapevoli ?  Allora OK. .....

consentimi di non concordare: la trasformazione avviene mediante una
matrice; salvo situazioni particolari, nelle quali la matrice potrebbe
avere rank insufficiente e quindi essere singolare(*), in condizioni
normali la matrice è invertibile quindi puoi ricostruire _esattamente_
i dati di partenza(**);

(*) un caso di questi potrebbe essere la proiezione da uno spazio 3D
ad uno 2D (la classica proiezione in pianta): perdo e quindi non potrò
più ricostruire la Z come tu giustamente dici;

(**) se traslo, ruoto e/o scalo un oggetto conservandolo nel suo
spazio posso risalire all'indietro, contrariamente a quanto tu,
erroneamente in questo caso, dici :-)


> A presto
>
> Geo

grazie, ciao,
giuliano
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
807 iscritti al 31/03/2016

[giohappy]

Roberto, le tue argomentazioni valgono anche per i raster, no?

Piuttosto un aspetto da valutare, nelle trasformazioni non lineari (es.
TSP) sarebbe il raffittimento dei vertici degli elementi lineari, perché la
deformazione dovrebbe poter agire su tutta la geometria. In un raster
questo avviene naturalmente, perché la trasformazione è applicata ad ogni
singolo pixel.

L'esigenza di georeferenziazione un raster, come dice Giuliano, è sentita
soprattutto da chi lavora con materiale CAD. È una richiesta frequente,
tant'è che altri sw GIS hanno gli strumenti per farlo. Vedi as es. lo
Spatial Adjustment di ArcMap.

Sarebbe un bel progettino da GsoC implementarlo nativamente (come il
georeferencer raster già esistente) partendo dal codice Grass, come
suggerito da Sandro.

Giovanni

Il 15 feb 2017 10:34, "Giuliano Curti" <[hidden email]> ha scritto:

> On 2/15/17, Geo DrinX <[hidden email]> wrote:
> > Buongiorno,
>
> ciao Roberto,
>
>
> > voglio solo dare un punto di riflessione sull'argomento "trasformazioni
> > affini".
> >
> > Parto da una domanda:  Quale è il motivo per cui si vuole deformare il
> > vettoriale ?
> > .........
> > Siamo consci che il vettoriale così deformato non è più un "documento
> > ufficiale" e che non possiamo più misurare aree distanze ed angoli da
> tali
> > vettori ?
>
> non sono in grado di dibattere le tue asserzioni circa la
> "ufficialità" degli oggetti trasformati (credo che la loro
> attendibilità derivi dai processi messi in campo che in questo caso
> attengono all'algebra lineare, in particolare al metodo dei minimi
> quadrati messo a punto da Gauss appena dopo il 1800 e pubblicati credo
> intorno al 1819);
> posso invece dire qualcosa intorno alla motivazione per cui è nato
> vectorGeoref, molto semplice, che ha due filoni paralleli:
> a) io arrivo da esperienza cad (architetto); in questa sono abituato a
> lavorare in coordinate locali, molto locali: uno spigolo del mio
> progetto rappresenterà l'origine (0,0,0) indipendentemente dalla
> latitudine e/o cartografia ufficiale del sito (di questo e altre
> caratteristiche terrò conto nel progetto in altro modo, ma non nelle
> coordinate);
> però, c'è sempre un però, potrei essere di fronte alla richiesta di
> georeferenziare il mio progetto; potrei anche essere di fronte a
> progetti stradali e/o di arredo urbano che, finita la fase di
> progettazione architettonica, vanno ricondotti alla cartografia
> ufficiale;
> b) ho avuto sempre molto interesse per la matematica; la pensione mi
> ha consentito di applicare risorse in questa direzione e quindi ho
> affrontato l'algebra lineare: la nascita del plugin è stata un pò
> l'esercizio con cui verificavo i miei progressi nella materia;
> c) ho detto due, ma forse c'è un terzo aspetto da considerare: esiste
> un bellissimo plugin che georeferenzia i raster (in modo molto più
> sofisticato del mio); avendo i problemi di cui al punto a) mi sembrava
> naturale disporre di uno strumento analogo anche per i vettoriali;
> quindi come vedi, tutto molto specifico e particolare; in realtà il
> plugin mi è "sfuggito di mano" sollevando qualche interesse nella
> comunità e si era parlato di portarlo, insieme al più maturo plugin
> per i raster, all'interno del core, ma poi francamente ho perso gli
> sviluppi, anche per la mia grande disabilità nella lingua inglese :-)
>
>
> > Sappiamo che tale risultato vettoriale non è più reversibile, e che non
> > possiamo più tornare alla geometria di partenza, rovesciando i parametri
> ?
> >
> > Ne siamo consapevoli ?  Allora OK. .....
>
> consentimi di non concordare: la trasformazione avviene mediante una
> matrice; salvo situazioni particolari, nelle quali la matrice potrebbe
> avere rank insufficiente e quindi essere singolare(*), in condizioni
> normali la matrice è invertibile quindi puoi ricostruire _esattamente_
> i dati di partenza(**);
>
> (*) un caso di questi potrebbe essere la proiezione da uno spazio 3D
> ad uno 2D (la classica proiezione in pianta): perdo e quindi non potrò
> più ricostruire la Z come tu giustamente dici;
>
> (**) se traslo, ruoto e/o scalo un oggetto conservandolo nel suo
> spazio posso risalire all'indietro, contrariamente a quanto tu,
> erroneamente in questo caso, dici :-)
>
>
> > A presto
> >
> > Geo
>
> grazie, ciao,
> giuliano
> _______________________________________________
> [hidden email]
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 807 iscritti al 31/03/2016

_______________________________________________
[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.
807 iscritti al 31/03/2016

[Giuliano Curti]

On 2/15/17, [hidden email] <[hidden email]> wrote:
> On Tue, 14 Feb 2017 22:54:01 +0100, Giuliano Curti wrote:
>> .....
>
> Giuliano,

ciao Sandro,


> il codice di Grass GIS offre gia' un'ottima implementazione
> basata sugli algoritmi RMSE e TSP.
> e per nostra fortuna e' scritto interamente in puro C (del
> tutto privo di .......
>
> personalmente penso che se tu riuscissi ad integrare
> il codice di Grass dentro al tuo plugin vectortGeoref
> sarebbe decisamente un'ottima iniziativa.
> .......

come forse avrai intuito dal mio scambio con GeoDrinx,
vectorGeoref nasce da un difetto di conoscenza (ovviamente
parlo per me) e non da un eccesso di conoscenza; infatti
non conosco il modulo di Grass e quindi mi sono divertito
a costruirmi in casa i pezzi che mi mancavano;


> se sei in qualche modo interessato posso fornirti
> (anche in privato) alcuni suggerimenti utili che
> derivano dalla mia esperienza di prima mano
> maturata quando ho sviluppato il modulo GCP per
> SpatiaLite.

da quando, 5 o 6 anni fa, mi sono avvicinato al mondo
QGIS/geospatial, mai e poi mai avrei immaginato di
trovarmi di fronte ad una tua proposta di collaborazione;
la cosa mi inorgoglisce e te ne sono infinitamente grato,
purtroppo la dura realtà è che anche il C rientra nei miei
"difetti di conoscenza" e credo che la cosa non abbia le
gambe per funzionare;
in generale cerco di approfittare di tutte le occasioni che
ho di imparare e sarei ben disposto a fare qualche
sacrificio, ma francamente se le difficoltà sono poco più
che banali temo sarebbe tempo perso;


> ciao Sandro

grazie, ciao,
giuliano
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
807 iscritti al 31/03/2016

[geodrinx]

>

> consentimi di non concordare: la trasformazione avviene mediante una
> matrice; salvo situazioni particolari, nelle quali la matrice potrebbe
> avere rank insufficiente e quindi essere singolare(*), in condizioni
> normali la matrice è invertibile quindi puoi ricostruire _esattamente_
> i dati di partenza(**);
>
> (*) un caso di questi potrebbe essere la proiezione da uno spazio 3D
> ad uno 2D (la classica proiezione in pianta): perdo e quindi non potrò
> più ricostruire la Z come tu giustamente dici;
>
> (**) se traslo, ruoto e/o scalo un oggetto conservandolo nel suo
> spazio posso risalire all'indietro, contrariamente a quanto tu,
> erroneamente in questo caso, dici :-)
>

Ovviamente, non parlavo di semplici traslazioni o rotazioni con cambio di
scala, che sono reversibili,
ma di trasformazioni complesse, quelle con più di tre punti di
collimazione, ed in cui i punti di destinazione sono "letti dall'ortofoto".

Poi, qualcuno pretende di far pagare canoni dipendenti dalle aree misurate
su tali vettori "deformati" ...

_______________________________________________
[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.
807 iscritti al 31/03/2016