[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