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" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> > A : Antonio Falciano <[EMAIL PROTECTED]> > Cc: "[email protected]" <[email protected]> > 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 <[EMAIL PROTECTED]> 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: > > [EMAIL PROTECTED] Comune di Grosseto > > jabber: [EMAIL PROTECTED] 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 [email protected] > > 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 > [EMAIL PROTECTED] > 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: [EMAIL PROTECTED] Comune di Grosseto jabber: [EMAIL PROTECTED] 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 [email protected] 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.
