[Gfoss] domande su dati catastali

[Bud P. Bruegger]

Sono d'accordo di affrontare in primo passo una trasformazione affine
per foglio.

Da uno studio molto velocie, mi sembra che gli SRID siano espressi in
Well Known Text format come descritto nello standard OpenGIS
"Coordinate Transformation Services" (sezione 7.2).  Non ho ancora
guardato in dettaglio, ma sezione 10.4 (pag 32) parla di affine.  

Una decisione da prendere e' se trasformare in un singolo passo (una
unica trasformazione affine) oppure in due (una trasformazione
analitica (possibilmente approximativa) piu' una affine).  Penso che
conceptualmente, ci sono poche differenze (qualcuno penso che spaglio),
ma possibilmente ci sono differenze numeriche notevoli se si fa un
passo grande con una trasformazione affine.  Che esperienze avete?

Il vantaggio di avere solo una singola trasformazione affine sarebbe
che non e' necessario conoscere gli origini per tutti i fogli.  

Se si facesse solo una singola trasformazione affine, pensando a voce
alta, si dovrebbe allora fare il segente per ogni foglio:

* identificare i correspondence points e derivare gli equivalenti
parametri di una trasformazione affine (al meno se non e' possibile di
listare i correspondence points direttamente).  

* esprimere questa trasformazione in formato WKT.  Penso oltre la
trasformazione stessa si debba trovare un modo di esprimere da quale
SR a quale altro la trasformazione converte.  

Penso che una carta scanzionata (raster) dovrebbe essere un buon
esempio per capire come fare.  La carta oritinale ha un suo SR ed la
scanzione introduce la necessita' di una trasformazione affine per
andare da coordinate di imagine (col/row) a x/y di questo SR.  Non ho
guardato se Mapserver o Geoserver usano SRID oppure un altro formato....

saluti
-b




On Tue, 11 Dec 2007 12:54:56 +0100
"Guglielmo R. Raimondi" <g.raimondi at glasic.it> wrote:

> 
> Potendo disporre del dato catastale ogni volta che si vuole
> (nel caso in cui si possa accedere al "Portale dei Comuni"),
> giudico molto importante la possibilita' di ripetere le
> operazioni di riproiezione e trasformazione sempre con gli
> stessi parametri, in maniera da consentira la valutazione
> delle modifiche nel tempo.
> 
> Una volta stabilita la tolleranza accettabile per
> l'accuratezza posizionale dei dati catastali in relazione
> all'accuratezza degli
> agli altri dati del nostro sistema informativo, non andrei a
> cercare la perfetta coincidenza di molti punti di controllo,
> utilizzando tecniche di triangolazione, ma mi accontenterei
> di realizzare la migliore trasformazione "affine" di un
> intero foglio.
> 
> Supponendo di voler comunque procedere alla triangolazione,
> starei molto attento alla scelta dei punti di controllo. Per
> mia piccola esperienza, esercitata sui fogli del Comune di
> Albanella (SA), dal confronto tra il dato catastale e quello
> della Carta Tecnica Regionale, e' emerso che alcuni edifici
> della carta catastale erano palesemente spostati (anche
> confrontando le distanze relative ad ad altri oggetti comuni
> tra le due fonti).
> 
> Bisogna ricordare che il dato catastale nasce con finalita'
> fiscali e che l'accuratezza posizionale non e' vincolante
> come per una carta tecnica (o per un'ortofoto).
> 
> Come primo passo, mi piacerebbe sistematizzare la
> riproiezione al volo in PostGIS. Qualcuno sa indicarmi i
> riferimenti da studiare?
> 
> Grazie,
> Guglielmo
> 
> 
> 
> ----- Original Message -----
> Da : "Bud P. Bruegger" <bud at comune.grosseto.it>
> A : Antonio Falciano <afalciano at yahoo.it>
> Cc: "gfoss at faunalia.com" <gfoss at faunalia.com>
> Oggetto : Re: [Gfoss] domande su dati catastali
> Data : Mon, 10 Dec 2007 17:04:57 +0100
> 
> > Ciao Antonio,
> > 
> > On Fri, 07 Dec 2007 17:45:38 +0100
> > Antonio Falciano <afalciano at yahoo.it> wrote:
> > > > Riguardo il tuo commento sul rubbersheeting che e' da
> > > > evitare, ti vorrei chiedere piu' dettagli.  
> > > 
> > > Questo tipo di trasformazioni sono da evitare perchè
> > > alterano completamente la geometria della cartografia
> > > catastale. Meglio una trasformazione affine!
> > 
> > Hmm. Capisco che dici ora e ovviamente e' legato alla
> > semantica dato al termine "rubber sheeting".  Io
> > personalmente penso molto di piu' in gradi di griscio: 
> > Normalmente, una trasformazione affine non e' possibile su
> > tutta l'area (che e' troppo grande) e si taglia in entita'
> > piu' piccole (ad esempio fogli che gia' esistono).  Il
> > rubbersheeting implementato da me anni fa (quello basato
> > su una triangulazione) fa la stessa cosa (non sono certo
> > se la trasformazione in ogni triangolo sia veramente
> > affine, penso di si, ma se no e' comunque un concetto
> > molto comparabile..) solo in aree piu' piccole.  
> > 
> > Allora la domanda che rimane e quanto piccole
> > devono/possono essere le aree a quali applicare una
> > trasformazione geometrica (affine o altro) e qui
> > certamente dipende dallo scopo...
> > 
> > Se lo scopo e' un match piu' buono possibile, e se si
> > accetta che la CTR proveniente da un rilievo
> > fotogrammetrico sia' piu' vero che la geometria del
> > catasto (magari solo su oggetti fisici come edifici, fiumi
> > ,...) allora una trasformazione che porta il catasto a
> > quella geometria vera e' una buona cosa.  
> > 
> > Mi rendo conto che una trasformazione affine per foglio e'
> > molto piu' robusto su scelte spagliate di "correspondence
> > points" ma sono sempre del'opinione che con correspondence
> > points buoni si puo arrivare a buoni risultati.  
> > 
> > [snip]
> > 
> > > Su piccole aree, stimare la trasformazione locale ed
> > > applicarla offre buoni risultati, ma utilizzarla "on the
> > fly" non credo serva a qualcosa.
> > 
> > Hmm.  Perche' no?  Se ho capito bene, il "on the fly" era
> > motivato nel fatto che si lascia i dati nel loro sistema
> > originale senza fisicamente rappresentare una
> > "interpretazione" non ufficiale.  
> > 
> > L'on the fly, se implementato veloce, allora mi sembra
> > ugualmente beneficiale per una trasformazione affine che
> > per una riproiezione analitica.  O c'e' qualcosa che non
> > vedo?
> > 
> > Mi chiedo se non e' gia' normale per dati raster di
> > trasformare on the fly sia per una trasformazione
> > geometrica (mappare i pixel a coordinate x/y di un sistema
> > di riferimento della carta) che anche una trasformazione
> > da un sistema di riferimento in un altro.  Forse spaglio?
> > 
> > > > * non capisco del tutto che intendono essattamente con
> > > > "fitting"  oppure "interventi geometrici locali", ma
> > > > non sono alla fine un rubber-sheeting? (anche questo
> > > > un termine molto vaghe che potrebbe riferirsi a cose
> > > ben diverse). 
> > > Attenzione: di trasformazioni ce ne sono tante e il
> > > rubbersheeting è proprio la più "distruttiva". Per
> > > intenderci, una trasformazione che rende le linee in
> > curve è, ai ns fini, particolarmente inadatta.
> > 
> > Hmm.  La trasformazione lineare usato in triangoli
> > preserve linee e magari "cambia direzione" ai confini di
> > un triangolo al altro  (allora dipende quanto fino sono i
> > triangoli).  
> > 
> > Mi sembra che vedere che fa in qualche esempio vero
> > sarebbe piu' facile che ragionare teoricamente...
> > 
> > saluti
> > -b
> > 
> > > 
> > > ciao
> > > Antonio
> > > 
> > > 
> > > 
> > 
> > 
> > -- 
> > Bud P. Bruegger, Ph.D.          +39-0564-488577 (voice), 
> > -21139 (fax) 
> >    European Chair, Global Collaboration Forum on eID
> >    Chair, Porvoo Subgroup on collab. govs/operating
> > systems
> >    Leader of the Permanent eID Status Observatory (PESO)
> > project Servizio Elaborazione Dati       e-mail: 
> > bud at comune.grosseto.it Comune di Grosseto              
> > jabber:  bud at jabber.no Via Ginori, 43                  
> > http://www.comune.grosseto.it/ 58100 Grosseto (Tuscany,
> > Italy) http://www.comune.grosseto.it/interopEID/
> > 
> > _______________________________________________
> > Prenota la tua maglietta GFOSS.it:
> > http://wiki.gfoss.it/index.php/Gadgets
> > Iscriviti all'associazione GFOSS.it:
> > http://www.gfoss.it/drupal/iscrizione Gfoss at faunalia.com
> > http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
> > Questa e' una lista di discussione pubblica aperta a
> > tutti.  I messaggi di questa lista non rispecchiano
> > necessariamente le posizioni dell'Associazione GFOSS.it.
> 
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Ing. Guglielmo R. Raimondi
> Glasic S.r.l.
> www.glasic.it
> g.raimondi at glasic.it
> cell.: 347 6720673
> tel.: 06 83502893
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^


-- 
Bud P. Bruegger, Ph.D.          +39-0564-488577 (voice),  -21139 (fax) 
   European Chair, Global Collaboration Forum on eID
   Chair, Porvoo Subgroup on collab. govs/operating systems
   Leader of the Permanent eID Status Observatory (PESO) project
Servizio Elaborazione Dati       e-mail:  bud at comune.grosseto.it
Comune di Grosseto               jabber:  bud at jabber.no
Via Ginori, 43                   http://www.comune.grosseto.it/
58100 Grosseto (Tuscany, Italy)
http://www.comune.grosseto.it/interopEID/