Re: [Gfoss] cambio coordinate da ovest ad est

2017-02-15 Per discussione Ely Parker 

Il 15/02/2017 19:04, Marco Guiducci ha scritto:

On Wed, 15 Feb 2017 17:38:12 +0100
Ely Parker  wrote:



le coordinate come hai detto su cartlab3 vanno in inserite su lat e
long  bessel su genova purtroppo su fiduciali.it il punto è espresso in
coordinate bessel rispetto castanea delle furie

Datum Geodetico Castanea delle Furie
Longitudine Bessel  0°30'04,944"W
Latitudine Bessel   37°30'05,651"N

ho guardato meglio il datum castanea


e ?


intanto prova a fare come ti ho detto io. le coordinate wgs trasformate in 
bessel, a meno di imprecisione, dovrebbero andare bene.

come ti ho detto ho provato ma il foglio cxf è un 80 metri  piu in la,  
ma come hai calcolato le coordinate in bessel? se faccio la sottrazione 
ad ogni modo il foglio se ne va a quel paese


___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
807 iscritti al 31/03/2016

Re: [Gfoss] cambio coordinate da ovest ad est

2017-02-15 Per discussione Marco Guiducci 
On Wed, 15 Feb 2017 17:38:12 +0100
Ely Parker  wrote:


> 
> le coordinate come hai detto su cartlab3 vanno in inserite su lat e 
> long  bessel su genova purtroppo su fiduciali.it il punto è espresso in 
> coordinate bessel rispetto castanea delle furie
> > Datum Geodetico Castanea delle Furie
> > Longitudine Bessel  0°30'04,944"W
> > Latitudine Bessel   37°30'05,651"N
> 

ho guardato meglio il datum castanea
intanto prova a fare come ti ho detto io. le coordinate wgs trasformate in 
bessel, a meno di imprecisione, dovrebbero andare bene.

-- 
Marco Guiducci 
Firenze, via di Novoli 26
055 4383194
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
807 iscritti al 31/03/2016

Re: [Gfoss] cambio coordinate da ovest ad est

2017-02-15 Per discussione Ely Parker 

Il 15/02/2017 18:17, Marco Guiducci ha scritto:

scusa continuo a non capire.
il punto che hai dato in wgs84, che è?
io ti ho dato le bessel su genova di quello. non ti basta come aggancio?
io ti ho dato:
6° 05' 48,0048"
37°30' 05,22828"


aspetta quelle che ti ho dato sono le stesse coordinate di una grande 
origine di cassini soldner (misterbianco) espressa in wgs84 e anche in 
bessel su castanea delle furie la fonte è fiduciali.it


ora per capire queste coordinate mi hai dato sono le coordinate del 
punto di misterbianco tradotte dal wgs84 a  bessel su genova? oppure 
sono le coordinate dell'orgine di genova, vorrei capire come le hai 
calcolate


se sono le coordinate dell'orgine di misterbianco allora lo sfasamento 
(sto georeferenziando dei cxf con cartlab) è di parecchio piu di 12 
metri , una 80ina circa, secondo te i grigliati gk2 possono sistemare la 
cosa anche con questa sfasatura?





___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
807 iscritti al 31/03/2016

Re: [Gfoss] cambio coordinate da ovest ad est

2017-02-15 Per discussione Marco Guiducci 
On Wed, 15 Feb 2017 17:38:12 +0100
Ely Parker  wrote:


> 
> le coordinate come hai detto su cartlab3 vanno in inserite su lat e 
> long  bessel su genova purtroppo su fiduciali.it il punto è espresso in 
> coordinate bessel rispetto castanea delle furie
> > Datum Geodetico Castanea delle Furie
> > Longitudine Bessel  0°30'04,944"W
> > Latitudine Bessel   37°30'05,651"N
> 
> 
> come cavolo faccio a passare dalle coordinate su castanea a quelle su 
> genova? oppure da quelle in wgs84 a quelle di bessel su genova 
> ovviamente con una certa precisione?
> 

scusa continuo a non capire.
il punto che hai dato in wgs84, che è?
io ti ho dato le bessel su genova di quello. non ti basta come aggancio?
io ti ho dato:
6° 05' 48,0048"
37°30' 05,22828"

la differenza, in metri, di latitudine tra quello che ti do io e quello che hai 
tu è circa 12 metri.
secondo me, ovviamente la latitudine essendo riferita all'equatore non cambia, 
e i 12 metri sono insiti nella precisione delle misure.
c'è solo una origine diversa sulla longitudine.
perciò, se il punto wgs è l'aggancio, sottrai 0°30'04,944 a 6°05'48,0048" 
(perché il punto è a ovest).
prova e sappici dire.

nota: i grigliati non esistono per le catastali. ma esistono tra wsg84 (etrf89) 
e Roma40. passare per roma40 è necessario perché è conosciuta la lat long di 
roma monte mario in bessel su genova. 

-- 
Marco Guiducci 
Firenze, via di Novoli 26
055 4383194
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
807 iscritti al 31/03/2016

Re: [Gfoss] cambio coordinate da ovest ad est

2017-02-15 Per discussione Ely Parker 



anch'io procederei così:
1) trasf da Cassini-Soldner (centro emanaz. Castanea delle Furie) a Gauss-Boaga
2) trasf da Gauss-Boaga a Cassini-Soldner (centro emanaz. Genova).

in questo modo avrai le coordinate in cassini soldner (x e y) ma non in 
latitudine e longitudine che mi servono per cartlab e per applicare i 
grigliati


inoltre ho il dubbio che applicando la trasformazione di cassini soldner 
a cusi lunghe distanze non ci sia qualche problema

___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
807 iscritti al 31/03/2016

Re: [Gfoss] cambio coordinate da ovest ad est

2017-02-15 Per discussione Ely Parker 

Il 15/02/2017 16:37, GUIDUCCI Marco ha scritto:



non è molto chiaro qual che scrivi.
in cartlab3 vanno inserite le lat long bessel su genova del punto di emanazione 
del sistema locale.
il tuo punto è questo?:
Longitudine WGS84   15.01883
Latitudine WGS8437.50304

interpretandolo in gradi sessadecimali, le bessel su genova potrebbero essere:
6.0976668 37.5014523 (la trasformazione è avvenuta passando dalle 
Roma40, senza grigliati Igm in CartLab2)

poi dai un altro punto in bessel a 30' di long. da dove? che cos'è? è il solito 
di prima che da in wgs ma con l'origine delle coordinate diversa?


mi scuso per la mancanza di chiarezza ,ma sto anzi stiamo perchè anche 
un amico è nella stessa situazione  fondendo,


le coordinate come hai detto su cartlab3 vanno in inserite su lat e 
long  bessel su genova purtroppo su fiduciali.it il punto è espresso in 
coordinate bessel rispetto castanea delle furie

Datum Geodetico Castanea delle Furie
Longitudine Bessel  0°30'04,944"W
Latitudine Bessel   37°30'05,651"N



come cavolo faccio a passare dalle coordinate su castanea a quelle su 
genova? oppure da quelle in wgs84 a quelle di bessel su genova 
ovviamente con una certa precisione?


___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
807 iscritti al 31/03/2016

Re: [Gfoss] cambio coordinate da ovest ad est

2017-02-15 Per discussione Ely Parker 

Il 15/02/2017 15:26, G. Allegri ha scritto:

Mi pare di capire che non si tratti solo di una rappresentazione diversa
della longitudine ma di un datum diverso.
Tu hai le coordinate rispetto al datum di Castanea delle Furie, invece lo
vorresti rispetto a Genova (IIM)?

Giovanni




esatto hai capito bene un cambio di datum

 mi scuso con tutti perchè non sono stato chiaro ma visto che non h 
trovato tool sono un po fuso perchè stavo provando ad arrivarci con il 
proj ma è peggio di andar di notte


se c'è qualche altro tool  va bene pure  ma mi occorre un sistema per 
esprimere le coordinate in termini di genova


se è col proj o cs2cs meglio ancora

l'opzione datum funziona con dei datum fissi, non so se c'è un modo per 
esprimere un altro modo dei datum diversi



___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
807 iscritti al 31/03/2016

Re: [Gfoss] cambio coordinate da ovest ad est

2017-02-15 Per discussione nino formica 
Ciao,

Concordo che si tratta di un cambio di datum.

Senza voler pretendere grandi precisioni (che richiedono i grigliati)
anch'io procederei così:
1) trasf da Cassini-Soldner (centro emanaz. Castanea delle Furie) a Gauss-Boaga
2) trasf da Gauss-Boaga a Cassini-Soldner (centro emanaz. Genova).

Qui ci sono entrambi le trasformazioni on-line:
http://www.borneo.name/topo/topo.html

Ma certo Stefano Campus avrà una soluzione più professionale !

Saluti
Nino

Il 15 febbraio 2017 15:55, Giuliano Curti  ha scritto:
> On 2/15/17, G. Allegri  wrote:
>> Mi pare di capire che non si tratti solo di una rappresentazione diversa
>> della longitudine ma di un datum diverso.
>> Tu hai le coordinate rispetto al datum di Castanea delle Furie, invece lo
>> vorresti rispetto a Genova (IIM)?
>
> anch'io ho capito questo;
> azzardo (per gioco): trasformazione da elissoidiche su C.d.F. a
> geocentriche e da queste ad elissoidiche su Ge;
> per essere invece seri: Alessandro  (mi scuso con lui per aver
> dimenticato il cognome e forse sbaglio anche il nome :-( ) cmq del
> gruppo dei torinesi (o piemontesi) che ti darà la risposta esatta in
> quanto esperto di trasformazioni; Skampus è una buona traccia per
> arrivare a lui;
>
>
>> Giovanni
>
> ciao,
> giuliano
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni 
> dell'Associazione GFOSS.it.
> 807 iscritti al 31/03/2016
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
807 iscritti al 31/03/2016

Re: [Gfoss] cambio coordinate da ovest ad est

2017-02-15 Per discussione GUIDUCCI Marco 


- Messaggio originale -
> Da: "Ely Parker" 
> A: "gfoss" 
> Inviato: Mercoledì, 15 febbraio 2017 13:25:36
> Oggetto: [Gfoss] cambio coordinate da ovest ad est

> salve a tutti non so se si può fare  anche se dovrebbe
> 
> ho questa punto
> 
> ID Origine87003
> Tipo  LOCALE
> Nome  Misterbianco
> Dettaglio Poggio Cardillo
> Trigonometrico
> Longitudine WGS84 15.01883
> Latitudine WGS84  37.50304
> Datum Geodetico   Castanea delle Furie
> Longitudine Bessel0°30'04,944"W
> Latitudine Bessel 37°30'05,651"N
> 
> mi serve come origine in un programma cartlab3 che però richiede in
> bessel su genova specificato in nord e in est e non in ovest
> 
> c'è qualche modo convertirlo in maniera semplice?
> 
> 


non è molto chiaro qual che scrivi.
in cartlab3 vanno inserite le lat long bessel su genova del punto di emanazione 
del sistema locale.
il tuo punto è questo?:
Longitudine WGS84   15.01883
Latitudine WGS8437.50304

interpretandolo in gradi sessadecimali, le bessel su genova potrebbero essere:
6.0976668 37.5014523 (la trasformazione è avvenuta passando dalle 
Roma40, senza grigliati Igm in CartLab2)

poi dai un altro punto in bessel a 30' di long. da dove? che cos'è? è il solito 
di prima che da in wgs ma con l'origine delle coordinate diversa?

ciao
marco
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
807 iscritti al 31/03/2016

Re: [Gfoss] cambio coordinate da ovest ad est

2017-02-15 Per discussione Giuliano Curti 
On 2/15/17, G. Allegri  wrote:
> Mi pare di capire che non si tratti solo di una rappresentazione diversa
> della longitudine ma di un datum diverso.
> Tu hai le coordinate rispetto al datum di Castanea delle Furie, invece lo
> vorresti rispetto a Genova (IIM)?

anch'io ho capito questo;
azzardo (per gioco): trasformazione da elissoidiche su C.d.F. a
geocentriche e da queste ad elissoidiche su Ge;
per essere invece seri: Alessandro  (mi scuso con lui per aver
dimenticato il cognome e forse sbaglio anche il nome :-( ) cmq del
gruppo dei torinesi (o piemontesi) che ti darà la risposta esatta in
quanto esperto di trasformazioni; Skampus è una buona traccia per
arrivare a lui;


> Giovanni

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

Re: [Gfoss] cambio coordinate da ovest ad est

2017-02-15 Per discussione G. Allegri 
Mi pare di capire che non si tratti solo di una rappresentazione diversa
della longitudine ma di un datum diverso.
Tu hai le coordinate rispetto al datum di Castanea delle Furie, invece lo
vorresti rispetto a Genova (IIM)?

Giovanni

Il giorno 15 febbraio 2017 15:20, Sieradz  ha scritto:

> /
> Ely Parker wrote
> > Longitudine Bessel0°30'04,944"W
> > c'è qualche modo convertirlo in maniera semplice?
>
> /
> Beh, il complemento a 360° sarebbe:
>
> Longitudine Bessel  *329°29'55,056"E*
>
> o mi sbaglio?
>
> --
> View this message in context: http://gfoss-geographic-free-
> and-open-source-software-italian-mailing.3056002.n2.
> nabble.com/cambio-coordinate-da-ovest-ad-est-tp7596637p7596639.html
> Sent from the Gfoss -- Geographic Free and Open Source Software - Italian
> mailing list mailing list archive at Nabble.com.
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 807 iscritti al 31/03/2016
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
807 iscritti al 31/03/2016

Re: [Gfoss] cambio coordinate da ovest ad est

2017-02-15 Per discussione Sieradz 
/
Ely Parker wrote
> Longitudine Bessel0°30'04,944"W
> c'è qualche modo convertirlo in maniera semplice?

/
Beh, il complemento a 360° sarebbe:

Longitudine Bessel  *329°29'55,056"E*

o mi sbaglio?

--
View this message in context: 
http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/cambio-coordinate-da-ovest-ad-est-tp7596637p7596639.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian 
mailing list mailing list archive at Nabble.com.
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
807 iscritti al 31/03/2016

Re: [Gfoss] affine transformation parametri

2017-02-15 Per discussione Geo DrinX 
>
> 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" ...
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
807 iscritti al 31/03/2016

[Gfoss] cambio coordinate da ovest ad est

2017-02-15 Per discussione Ely Parker 

salve a tutti non so se si può fare  anche se dovrebbe

ho questa punto

ID Origine  87003
TipoLOCALE
NomeMisterbianco
Dettaglio   Poggio Cardillo
Trigonometrico  
Longitudine WGS84   15.01883
Latitudine WGS8437.50304
Datum Geodetico Castanea delle Furie
Longitudine Bessel  0°30'04,944"W
Latitudine Bessel   37°30'05,651"N

mi serve come origine in un programma cartlab3 che però richiede in 
bessel su genova specificato in nord e in est e non in ovest


c'è qualche modo convertirlo in maniera semplice?

___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
807 iscritti al 31/03/2016

Re: [Gfoss] affine transformation parametri

2017-02-15 Per discussione G. Allegri 
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"  ha scritto:

> On 2/15/17, Geo DrinX  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
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 807 iscritti al 31/03/2016
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
807 iscritti al 31/03/2016

Re: [Gfoss] affine transformation parametri

2017-02-15 Per discussione Giuliano Curti 
On 2/15/17, Geo DrinX  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
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
807 iscritti al 31/03/2016

Re: [Gfoss] affine transformation parametri

2017-02-15 Per discussione Geo DrinX 
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  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,  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
> > ___
> > Gfoss@lists.gfoss.it
> > http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> > Questa e' una lista di discussione pubblica aperta a tutti.
> > I messaggi di questa lista non hanno relazione diretta con le posizioni
> > dell'Associazione GFOSS.it.
> > 807 iscritti al 31/03/2016
>
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 807 iscritti al 31/03/2016
>
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.

Re: [Gfoss] affine transformation parametri

2017-02-15 Per discussione 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
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
807 iscritti al 31/03/2016

Re: [Gfoss] affine transformation parametri

2017-02-15 Per discussione G. Allegri 
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,  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
> ___
> Gfoss@lists.gfoss.it
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 807 iscritti al 31/03/2016
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
807 iscritti al 31/03/2016

Re: [Gfoss] affine transformation parametri

2017-02-15 Per discussione 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
___
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni 
dell'Associazione GFOSS.it.
807 iscritti al 31/03/2016