[Gfoss] domande su dati catastali

Fabio D'Ovidio fabiodovidio a gmail.com
Mar 11 Dic 2007 14:06:57 CET


Guglielmo,
sono pienamente d'accordo con te!
Anche io ho ragionato in questi termini e appena possibile (presto) 
metterò su una paginetta sul wiki in cui spiegherò le operazioni che ho 
fatto ragionando foglio per foglio.
Credo di essere giunto ad un risultato accettabile, rispetto alle 
finalità del catasto (fiscali, come hai detto tu).
Se qualcuno utilizza o ha utilizzato altri metodi, si faccia avanti ;-)

Ciao

-- 
Ing. Fabio D'Ovidio

iQuadro - Informatica e Innovazione s.r.l.
Via C. Pisacane 23, Aversa (CE) - 81031
Web : www.ii2.it
Tel.: 081 197 57 600
mail: fabiodovidio a gmail.com



Guglielmo R. Raimondi ha scritto:
> 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 a comune.grosseto.it>
> A : Antonio Falciano <afalciano a yahoo.it>
> Cc: "gfoss a faunalia.com" <gfoss a 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 a 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 a comune.grosseto.it Comune di Grosseto              
>> jabber:  bud a 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 a 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 a glasic.it
> cell.: 347 6720673
> tel.: 06 83502893
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> _______________________________________________
> 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 a 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.
>
>   




Maggiori informazioni sulla lista Gfoss