[Gfoss] domande su dati catastali

Piergiorgio Cipriano pg.cipriano a gmail.com
Gio 6 Dic 2007 10:56:06 CET


Bud,
ma il Comune di Grosseto ha gi chiesto a Regione Toscana, visto che  tra
gli enti sviluppatori di Sigma Ter [1] ??
Credo che tutte le questioni che hai sollevato (formato, sistema
riferimento, poligoni, ...) dovrebbero essere infatti gi risolte dai
servizi e dalle applicazioni sviluppate in Sigma Ter.
Oltre al fatto che non c' solo cartografia, ma anche dati su UIU e
proprietari.

[1] http://www.sigmater.it/


pg


Il 06/12/07, Bud P. Bruegger <bud a comune.grosseto.it> ha scritto:
>
> Buongiorno a tutti,
>
> Finalmente, noi al Comune di Grosseto facciamo alcuni passi in avanti
> con il GIS e ovviamente sceliamo open source.
>
> Un problema che dobbiamo affrontare e' come meglio caricare dati
> catastali nel GIS.  Penso che questo dovrebbe essere un problema comune
> e vorrei chiedere la vostra esperienza.  Se fosse necessario di
> sviluppare qualcosa, allora vorrei trovere un modo di farlo in open
> source cosi rimane a disposizione della comunita' (vedi sotto).
>
> Dopo una indagine veloce, vedo tre problemi di base con i dati
> catastali:
>
> (1) il formato in quale caricarlo
>
> (2) la poligonizzazione da linee e testi
>
> (3) la georeferenziazione
>
> Nel seguito scrivo le mie idee iniziale sui argomenti e spero che
> qualcuno mi risponde.
>
> (1) formato:
>
> Sembra che il catasto mette a disposizione i dati in tre formati:  CXF,
> DXF, CML.  Ho guardato particolarmente CML (un DTD di XML) sperando che
> abbia poligoni con attributi, ma sembra che sia del tutto
> spagghetti...
>
> Cercando in rete non ho trovato un parser/convertitore di CML in open
> source ma forse non si perde niente di lettere i dati in DXF.  Pero'
> se non spaglio, OGR non legge attualmente DXF.
>
> Allora la domanda:  c'e' gia' una soluzione pronta oppure deve essere
> sviluppata.   Nel secondo caso, che sarebbe la soluzione giusta; ad
> esempio un convertitore da dxf a shape (che lascia spagghetti), meglio
> uno da CML?, etc..
>
> (2) poligonizzazione:
>
> Su prima vista, le linee (confini di poligoni) contentuto nei file del
> catasto sono chiusi (ripetono il punto di inizio alla fine) e
> dovrebbero essere "validi" per convertirli in poligoni.  Pero, mi
> sembra che gli attributi non sono logicamente legati al poligono ed e'
> necessario un "point in polygon" per attacare gli attibuti al
> poligono.
>
> La Domanda:  C'e' qualcuno che ha esperienza in poligonizzare files
> catastali?  E' possibile una automatizzazione completa o ci sono casi
> in quale il punti di posizionamento testo non sta nel poligono? (o
> altri casi di eccezione)?
>
> (3) georeferenziazione:
>
> La nostra cartografia di base e' in Gauss Boaga (come deciso dalla
> nostra Regione).  Mi risulta che con l'eccezione delle aree costaliere,
> tutti i dati catastali sono in Cassini Soldner.
>
> Il mio obiettivo sarebbe di trovare una soluzione di convertire i dati
> in Gauss Boaga che:
>
> * puo essere applicato ripetutamente in automatico ogni volta che esce
> una nuova versione dei dati catastali
>
> * che quanto possibile elimina i deformazioni locali presente nei dati.
>
> Sarei molto interessato di sentire la vostra esperienza.  La mia
> impressione al momento e' che
>
> * una trasformazione analitica (proiezione, datum) non e' la soluzione
> ottima perche' non corregge le deformazioni locali
>
> * una trasformazione geometrica (Helmert, polinominale di 8
> parametri..) basandosi su "control points" e "corrispondence points"
> sia piu' facile ma ancora non corregge abbastanza le deformazioni
> locali.   A proposito, mi puo confermare qualcuno che il catasto non
> fornisce dati (control points etc.) che possono essere usati per
> determinare i parametri di una tale trasformazione?
>
> * un rubbersheeting su sotte parti del foglio sarebbe ideale.  Io avevo
> tanti anni fa (nel contesto della digitalizzazione di fogli catastali
> in Svizzera) scritto un sw che fa una trasformazione per foglio in un
> primo passo (un least square fit), e in un secondo passo fa una
> trinagulazione (Delaunay) tra control e correspondence points per poi
> applicare una trasformazione in ogni triangolo (basato su "linear
> coordinates").  Anche se questo sw (che ho scritto per una ditta) ora
> potrei certo usare senza infringere qualche copyright, non so se il mio
> floppy mac di 15 anni fa e' sempre leggibile...  Esiste qualcosa di
> simile gia'?
>
> Che e' la vostra esperienza?  Come si deve meglio procedere?
>
> Magari se ci sono buoni soluzioni possiamo mettere qualche parte una
> documento di "best practise" che puo essere riusato da persone come me
> che devono gestire dati catastali..
>
> mille grazie in anticipo per tutti suggerimenti e input
>
> saluti
> -b
>
> --
> 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/
>
> _______________________________________________
> Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
> Gfoss a faunalia.com
> http://www.faunalia.com/cgi-bin/mailman/listinfo/gfoss
> 281 iscritti al 26.11.2007
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non rispecchiano necessariamente
> le posizioni dell'Associazione GFOSS.it.
>



-- 
Piergiorgio Cipriano
pg.cipriano a gmail.com

("perch la terra dei cachi  la terra dei cachi ..!")
-------------- parte successiva --------------
Un allegato HTML  stato rimosso...
URL: http://www.faunalia.com/pipermail/gfoss/attachments/20071206/8a365443/attachment.htm 


Maggiori informazioni sulla lista Gfoss