[Gfoss] domande su dati catastali

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@comune.grosseto.it
Comune di Grosseto jabber: bud@jabber.no
Via Ginori, 43 http://www.comune.grosseto.it/
58100 Grosseto (Tuscany, Italy)
http://www.comune.grosseto.it/interopEID/

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@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@comune.grosseto.it
Comune di Grosseto jabber: bud@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@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@gmail.com

(“perchè la terra dei cachi è la terra dei cachi …!”)

Sono anche io molto interessato alla questione!
Credo che i problemi che hai indicato sono quelli critici per quanto riguarda i dati del catasto.

Per quella che fino ad ora (pochi giorni :wink: ) è stata la mia esperienza su questo tipo di dati posso dire che:

io sto scaricando e utilizzando i CXF ed un programma (per ora) CXFtoShape scaricato da:
http://www.fiduciali.it/modules.php?name=Downloads
che ti consente di dare in ingresso anche un file XML che contiene le coordinate dei punti omologhi per effettuare una traslazione rigida.
Purtroppo la trasformazione non è precisa per vari motivi:
- le deformazioni non vengono corrette
- i punti fiduciali dati dall'Agenzia del territorio quasi mai sono attendibili (almeno per quello che ho visto fin'ora sulle monografie scaribili dal sito)

Per quanto riguarda i DXF puoi scaricare dxf2Postgis
http://www.freegis-italia.org/index.php?option=com_content&task=view&id=314&Itemid=86
e poi se vuoi puoi esportare tutto in SHP. Anche qui però si presenta il problema della georeferenziazione! Non hai la possibilità di dare i punti omologhi e quindi devi ricorrere ad altri SW

Per il resto, attualmente mi sto facendo una cultura in merito per cui l'idea di mettere su una paginetta wiki in cui vengono indicate le "best practise" mi sembra ottima!!

--
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@gmail.com

Bud P. Bruegger 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

Grazie per il puntatore. Ora chiamo la Regione per vedere che mi
dicono.

Che cosa e' UIU?

grazie
-b

On Thu, 6 Dec 2007 10:56:06 +0100
"Piergiorgio Cipriano" <pg.cipriano@gmail.com> wrote:

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@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@comune.grosseto.it
> Comune di Grosseto jabber: bud@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@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@gmail.com

("perchè la terra dei cachi è la terra dei cachi ..!")

--
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@comune.grosseto.it
Comune di Grosseto jabber: bud@jabber.no
Via Ginori, 43 http://www.comune.grosseto.it/
58100 Grosseto (Tuscany, Italy)
http://www.comune.grosseto.it/interopEID/

Fabio D'Ovidio ha scritto:

Per il resto, attualmente mi sto facendo una cultura in merito per cui
l'idea di mettere su una paginetta wiki in cui vengono indicate le "best
practise" mi sembra ottima!!

Fare una pagina wiki e' d'obbligo!
Suvvia, procedete.
pc
--
Paolo Cavallini, see: http://www.faunalia.it/pc

Si, sono d'accordo. Prima però vorrei confrontarmi con tutti quelli in lista che sicuramente ne sanno più di me in materia di catasto.
C'è qualcuno di buona volontà che può fare una panoramica veloce anche semplicemnte con qualche link a documentazione varia
e rispondere ai problemi esposti poco fa?

Paolo Cavallini ha scritto:

Fabio D'Ovidio ha scritto:

Per il resto, attualmente mi sto facendo una cultura in merito per cui l'idea di mettere su una paginetta wiki in cui vengono indicate le "best practise" mi sembra ottima!!
    
Fare una pagina wiki e' d'obbligo!
Suvvia, procedete.
pc
  
--
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@gmail.com

Buonissimi link! grazie. Una volta che abbiamo provati come fare,
scriviamo la pagine sul wiki..

Ora sento SigmaTer..

-b

On Thu, 06 Dec 2007 11:08:53 +0100
Fabio D'Ovidio <fabiodovidio@gmail.com> wrote:

Sono anche io molto interessato alla questione!
Credo che i problemi che hai indicato sono quelli critici per quanto
riguarda i dati del catasto.

Per quella che fino ad ora (pochi giorni :wink: ) è stata la mia esperienza
su questo tipo di dati posso dire che:

io sto scaricando e utilizzando i CXF ed un programma (per ora)
CXFtoShape scaricato da:
http://www.fiduciali.it/modules.php?name=Downloads
che ti consente di dare in ingresso anche un file XML che contiene le
coordinate dei punti omologhi per effettuare una traslazione rigida.
Purtroppo la trasformazione non è precisa per vari motivi:
- le deformazioni non vengono corrette
- i punti fiduciali dati dall'Agenzia del territorio quasi mai sono
attendibili (almeno per quello che ho visto fin'ora sulle monografie
scaribili dal sito)

Per quanto riguarda i DXF puoi scaricare dxf2Postgis
http://www.freegis-italia.org/index.php?option=com_content&task=view&id=314&Itemid=86
e poi se vuoi puoi esportare tutto in SHP. Anche qui però si presenta il
problema della georeferenziazione! Non hai la possibilità di dare i
punti omologhi e quindi devi ricorrere ad altri SW

Per il resto, attualmente mi sto facendo una cultura in merito per cui
l'idea di mettere su una paginetta wiki in cui vengono indicate le "best
practise" mi sembra ottima!!

--
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@gmail.com

Bud P. Bruegger 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@comune.grosseto.it
Comune di Grosseto jabber: bud@jabber.no
Via Ginori, 43 http://www.comune.grosseto.it/
58100 Grosseto (Tuscany, Italy)
http://www.comune.grosseto.it/interopEID/

Fabio D'Ovidio ha scritto:

Si, sono d'accordo. Prima però vorrei confrontarmi con tutti quelli in
lista che sicuramente ne sanno più di me in materia di catasto.

Posso correggerti?
Non *prima*: intanto mettete giu' gli elementi gia' emersi, non
aspettate di arrivare ad un risultato (release early, release often).
Salutoni.
pc
--
Paolo Cavallini, see: http://www.faunalia.it/pc

Bud P. Bruegger ha scritto:

Che cosa e’ UIU?

Unità Immobiliare Urbana.

Credo sia molto utile dare un’occhiata a questa presentazione (pps):
http://www.rete.toscana.it/sett/territorio/carto/progetti/catasto/interventi/sanfelice_agenziaterritorio.pps

pg

2007/12/6, Bud P. Bruegger < bud@comune.grosseto.it>:

Grazie per il puntatore. Ora chiamo la Regione per vedere che mi
dicono.

Che cosa e’ UIU?

grazie
-b

On Thu, 6 Dec 2007 10:56:06 +0100
“Piergiorgio Cipriano” <pg.cipriano@gmail.com> wrote:

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@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@comune.grosseto.it
Comune di Grosseto jabber: bud@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@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@gmail.com

(“perchè la terra dei cachi è la terra dei cachi …!”)


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@comune.grosseto.it
Comune di Grosseto jabber: bud@jabber.no
Via Ginori, 43 http://www.comune.grosseto.it/
58100 Grosseto (Tuscany, Italy)
http://www.comune.grosseto.it/interopEID/


Piergiorgio Cipriano
pg.cipriano@gmail.com

(“perchè la terra dei cachi è la terra dei cachi …!”)

Ciao Fabio,

io sto scaricando e utilizzando i CXF ed un programma (per ora)
CXFtoShape scaricato da:
http://www.fiduciali.it/modules.php?name=Downloads
che ti consente di dare in ingresso anche un file XML che contiene le
coordinate dei punti omologhi per effettuare una traslazione rigida.
Purtroppo la trasformazione non è precisa per vari motivi:
- le deformazioni non vengono corrette
- i punti fiduciali dati dall'Agenzia del territorio quasi mai sono
attendibili (almeno per quello che ho visto fin'ora sulle monografie
scaribili dal sito)

Non sono ancora riuscito di scaricarlo (mi sono registrato ma non e'
arrivato ancora la mail con il pwd).

E' un esecutibile solo windows sotto licenza freeware?

Mi viene una domanda: come si comparano i vari formati? Quale e' il
migliore da usare in input--oppure sono tutti concetualmente uguali
(spaghetti..)? Pensavo che CML essendo il formato piu' moderno sia
piu' che solo spagghetti--ma non mi sembra.. CXF non ho neanche
guardato..

saluti
-b

esiste anche questo:
http://www.consulcad.it/download.aspx
Vito

----- Original Message ----- From: "Bud P. Bruegger" <bud@comune.grosseto.it>
To: "Fabio D'Ovidio" <fabiodovidio@gmail.com>
Cc: <gfoss@faunalia.com>
Sent: Thursday, December 06, 2007 12:49 PM
Subject: Re: [Gfoss] domande su dati catastali

Ciao Fabio,

io sto scaricando e utilizzando i CXF ed un programma (per ora)
CXFtoShape scaricato da:
http://www.fiduciali.it/modules.php?name=Downloads
che ti consente di dare in ingresso anche un file XML che contiene le
coordinate dei punti omologhi per effettuare una traslazione rigida.
Purtroppo la trasformazione non è precisa per vari motivi:
- le deformazioni non vengono corrette
- i punti fiduciali dati dall'Agenzia del territorio quasi mai sono
attendibili (almeno per quello che ho visto fin'ora sulle monografie
scaribili dal sito)

Non sono ancora riuscito di scaricarlo (mi sono registrato ma non e'
arrivato ancora la mail con il pwd).

E' un esecutibile solo windows sotto licenza freeware?

Mi viene una domanda: come si comparano i vari formati? Quale e' il
migliore da usare in input--oppure sono tutti concetualmente uguali
(spaghetti..)? Pensavo che CML essendo il formato piu' moderno sia
piu' che solo spagghetti--ma non mi sembra.. CXF non ho neanche
guardato..

saluti
-b

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@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.

Vito Borneo ha scritto:

esiste anche questo:
http://www.consulcad.it/download.aspx

Non mi fate fare sempre il cerbero! :slight_smile:
Ricodriamoci che questa lista e' per lo sviluppo del software *libero*
ed *open source*.
Grazie.
pc

--
Paolo Cavallini, see: http://www.faunalia.it/pc

Hei Piergiorgio,

grazie per il link interessante! Non sapevo della convenzione tra
Regione e Catasto di mettere a posto i vector anche per la nostra
provincia. Ma mi sembra che ancora il lavoro non sia stato fatto per
tutta la provincia e che per il comune di grosseto, i dati vettoriali
hanno un buco temporale di 6 anni (1995-2001). GRRRRR.

La Regione sembra che scarica i dati catastali una volta al mese e sono
disponibile tramite SPC ma senza conversione da Casini Soldner a Gauss
Boaga. Ma sembra di aver capito che la regione usa una trasformazione
globale per questa trasformazione (e chiedero' i parametri).

saluti
-b

On Thu, 6 Dec 2007 12:04:34 +0100
"Piergiorgio Cipriano" <pg.cipriano@gmail.com> wrote:

Bud P. Bruegger ha scritto:
> Che cosa e' UIU?

Unità Immobiliare Urbana.

Credo sia molto utile dare un'occhiata a questa presentazione (pps):
http://www.rete.toscana.it/sett/territorio/carto/progetti/catasto/interventi/sanfelice_agenziaterritorio.pps

pg

2007/12/6, Bud P. Bruegger <bud@comune.grosseto.it>:
>
> Grazie per il puntatore. Ora chiamo la Regione per vedere che mi
> dicono.
>
> Che cosa e' UIU?
>
> grazie
> -b
>
> On Thu, 6 Dec 2007 10:56:06 +0100
> "Piergiorgio Cipriano" <pg.cipriano@gmail.com> wrote:
>
> > 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@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@comune.grosseto.it
> > > Comune di Grosseto jabber: bud@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@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@gmail.com
> >
> > ("perchè la terra dei cachi è la terra dei cachi ..!")
> >
>
>
> --
> 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@comune.grosseto.it
> Comune di Grosseto jabber: bud@jabber.no
> Via Ginori, 43 http://www.comune.grosseto.it/
> 58100 Grosseto (Tuscany, Italy)
> http://www.comune.grosseto.it/interopEID/
>

--
Piergiorgio Cipriano
pg.cipriano@gmail.com

("perchè la terra dei cachi è la terra dei cachi ..!")

--
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@comune.grosseto.it
Comune di Grosseto jabber: bud@jabber.no
Via Ginori, 43 http://www.comune.grosseto.it/
58100 Grosseto (Tuscany, Italy)
http://www.comune.grosseto.it/interopEID/

E lo so, ma quando c'è è bene,
quando non c'è bisogna arrangiarsi
Comunque ho segnalato
UteCXF ver. 3 FULL da CXF a DXF o SHP (shape File) e dal DWG al CXF ...
perchè è comunque freeware (almeno)
Vito

----- Original Message ----- From: "Paolo Cavallini" <cavallini@faunalia.it>
To: "Vito Borneo" <borneo.vito@tiscali.it>
Cc: <gfoss@faunalia.com>
Sent: Thursday, December 06, 2007 2:25 PM
Subject: Re: [Gfoss] domande su dati catastali

Vito Borneo ha scritto:

esiste anche questo:
http://www.consulcad.it/download.aspx

Non mi fate fare sempre il cerbero! :slight_smile:
Ricodriamoci che questa lista e' per lo sviluppo del software *libero*
ed *open source*.
Grazie.
pc

--
Paolo Cavallini, see: http://www.faunalia.it/pc

Questa è la mailing list di Gfoss, che sta per:

Geospatial Free and Open source Software

e non per

Geospatial Freeware and Open source Software

Per comunicazioni riguardanti applicativi al di fuori dell'ambito della lista, siete
pregati di usare mail private.

Grazie

Luca

Vito Borneo ha scritto:

E lo so, ma quando c'è è bene,
quando non c'è bisogna arrangiarsi
Comunque ho segnalato
UteCXF ver. 3 FULL da CXF a DXF o SHP (shape File) e dal DWG al CXF ...
perchè è comunque freeware (almeno)
Vito

La Regione sembra che scarica i dati catastali una volta al mese e sono
disponibile tramite SPC ma senza conversione da Casini Soldner a Gauss
Boaga.

Tieni presente che il dato catastale ufficiale rilasciato dalla AdT e' in cassini-soldner.
Se lo trasformi in un altro sistema di riferimento, per quanto buona puo' essere la trasformazione, il dato non e' piu' quello ufficiale e quindi va usato con attenzione e solo nei casi in cui non
serve il dato ufficiale.

hanno un buco temporale di 6 anni (1995-2001). GRRRRR.

Cosa intendi quando dici che i dati hanno un buco temporale, esiste l'ante 1995 e il post 2001 ?

Boaga. Ma sembra di aver capito che la regione usa una trasformazione
globale per questa trasformazione (e chiedero' i parametri).

Non capisco, li trasforma o non li trasforma ?

Grazie,

Andrea.

On Thu, 6 Dec 2007 16:34:16 +0100, Bud P. Bruegger wrote:

Hei Piergiorgio,

grazie per il link interessante! Non sapevo della convenzione tra
Regione e Catasto di mettere a posto i vector anche per la nostra
provincia. Ma mi sembra che ancora il lavoro non sia stato fatto per
tutta la provincia e che per il comune di grosseto, i dati vettoriali
hanno un buco temporale di 6 anni (1995-2001). GRRRRR.

La Regione sembra che scarica i dati catastali una volta al mese e sono
disponibile tramite SPC ma senza conversione da Casini Soldner a Gauss
Boaga. Ma sembra di aver capito che la regione usa una trasformazione
globale per questa trasformazione (e chiedero' i parametri).

saluti
-b

On Thu, 6 Dec 2007 12:04:34 +0100
"Piergiorgio Cipriano" <pg.cipriano@gmail.com> wrote:

Bud P. Bruegger ha scritto:
> Che cosa e' UIU?

Unità Immobiliare Urbana.

Credo sia molto utile dare un'occhiata a questa presentazione (pps):
http://www.rete.toscana.it/sett/territorio/carto/progetti/catasto/interventi/sanfelice_agenziaterritorio.pps

pg

2007/12/6, Bud P. Bruegger <bud@comune.grosseto.it>:
>
> Grazie per il puntatore. Ora chiamo la Regione per vedere che mi
> dicono.
>
> Che cosa e' UIU?
>
> grazie
> -b
>
> On Thu, 6 Dec 2007 10:56:06 +0100
> "Piergiorgio Cipriano" <pg.cipriano@gmail.com> wrote:
>
> > 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@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@comune.grosseto.it
> > > Comune di Grosseto jabber: bud@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@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@gmail.com
> >
> > ("perchè la terra dei cachi è la terra dei cachi ..!")
> >
>
>
> --
> 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@comune.grosseto.it
> Comune di Grosseto jabber: bud@jabber.no
> Via Ginori, 43 http://www.comune.grosseto.it/
> 58100 Grosseto (Tuscany, Italy)
> http://www.comune.grosseto.it/interopEID/
>

--
Piergiorgio Cipriano
pg.cipriano@gmail.com

("perchè la terra dei cachi è la terra dei cachi ..!")

--
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@comune.grosseto.it
Comune di Grosseto jabber: bud@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@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.

On Thu, 06 Dec 2007 18:52:51 +0100
"Andrea P." <cerebrogis@ipergeo.org> wrote:

>La Regione sembra che scarica i dati catastali una volta al mese e sono
>disponibile tramite SPC ma senza conversione da Casini Soldner a Gauss
>Boaga.

Tieni presente che il dato catastale ufficiale rilasciato dalla AdT e' in cassini-soldner.
Se lo trasformi in un altro sistema di riferimento, per quanto buona puo' essere la trasformazione, il dato non e' piu' quello ufficiale e quindi va usato con attenzione e solo nei casi in cui non
serve il dato ufficiale.

Ok. Noi comune siamo interessato ad avere il catasto come layer nel
GIS che combacia con la CTR. A chi serve il dato ufficiale non lo
prende dal GIS comunale ma dal catasto..

>hanno un buco temporale di 6 anni (1995-2001). GRRRRR.

Cosa intendi quando dici che i dati hanno un buco temporale, esiste l'ante 1995 e il post 2001 ?

Sembra che nei vettoriali disponibili sono tutto fino a 2001 e tutti
cambiamenti dal 2001 in poi. Non risultano nessuna modifica tra 95 a
2001...

>Boaga. Ma sembra di aver capito che la regione usa una trasformazione
>globale per questa trasformazione (e chiedero' i parametri).

Non capisco, li trasforma o non li trasforma ?

I dati disponibile online dalla regione in SPC non sono trasformati.
Loro per scopi loro oppure per richieste offline usano una
trasformazione..

saluti
-b

Grazie,

Andrea.

On Thu, 6 Dec 2007 16:34:16 +0100, Bud P. Bruegger wrote:

>Hei Piergiorgio,

>grazie per il link interessante! Non sapevo della convenzione tra
>Regione e Catasto di mettere a posto i vector anche per la nostra
>provincia. Ma mi sembra che ancora il lavoro non sia stato fatto per
>tutta la provincia e che per il comune di grosseto, i dati vettoriali
>hanno un buco temporale di 6 anni (1995-2001). GRRRRR.

>La Regione sembra che scarica i dati catastali una volta al mese e sono
>disponibile tramite SPC ma senza conversione da Casini Soldner a Gauss
>Boaga. Ma sembra di aver capito che la regione usa una trasformazione
>globale per questa trasformazione (e chiedero' i parametri).

>saluti
>-b

>On Thu, 6 Dec 2007 12:04:34 +0100
>"Piergiorgio Cipriano" <pg.cipriano@gmail.com> wrote:

>> Bud P. Bruegger ha scritto:
>> > Che cosa e' UIU?
>>
>> Unità Immobiliare Urbana.
>>
>> Credo sia molto utile dare un'occhiata a questa presentazione (pps):
>> http://www.rete.toscana.it/sett/territorio/carto/progetti/catasto/interventi/sanfelice_agenziaterritorio.pps
>>
>> pg
>>
>>
>> 2007/12/6, Bud P. Bruegger <bud@comune.grosseto.it>:
>> >
>> > Grazie per il puntatore. Ora chiamo la Regione per vedere che mi
>> > dicono.
>> >
>> > Che cosa e' UIU?
>> >
>> > grazie
>> > -b
>> >
>> > On Thu, 6 Dec 2007 10:56:06 +0100
>> > "Piergiorgio Cipriano" <pg.cipriano@gmail.com> wrote:
>> >
>> > > 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@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@comune.grosseto.it
>> > > > Comune di Grosseto jabber: bud@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@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@gmail.com
>> > >
>> > > ("perchè la terra dei cachi è la terra dei cachi ..!")
>> > >
>> >
>> >
>> > --
>> > 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@comune.grosseto.it
>> > Comune di Grosseto jabber: bud@jabber.no
>> > Via Ginori, 43 http://www.comune.grosseto.it/
>> > 58100 Grosseto (Tuscany, Italy)
>> > http://www.comune.grosseto.it/interopEID/
>> >
>>
>>
>>
>> --
>> Piergiorgio Cipriano
>> pg.cipriano@gmail.com
>>
>> ("perchè la terra dei cachi è la terra dei cachi ..!")
>>

>--
>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@comune.grosseto.it
>Comune di Grosseto jabber: bud@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@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.

_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@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.

--
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@comune.grosseto.it
Comune di Grosseto jabber: bud@jabber.no
Via Ginori, 43 http://www.comune.grosseto.it/
58100 Grosseto (Tuscany, Italy)
http://www.comune.grosseto.it/interopEID/

Bud P. Bruegger ha scritto:

On Thu, 06 Dec 2007 18:52:51 +0100
"Andrea P." <cerebrogis@ipergeo.org> wrote:

La Regione sembra che scarica i dati catastali una volta al mese e sono
disponibile tramite SPC ma senza conversione da Casini Soldner a Gauss
Boaga.

Tieni presente che il dato catastale ufficiale rilasciato dalla AdT e' in cassini-soldner.
Se lo trasformi in un altro sistema di riferimento, per quanto buona puo' essere la trasformazione, il dato non e' piu' quello ufficiale e quindi va usato con attenzione e solo nei casi in cui non serve il dato ufficiale.

Bud ti ringrazio davvero per aver sollevato queste problematiche in
lista. Davvero interessante questo post!
Personalmente, per esigenze lavorative ed in concomitanza con un master
in Sistemi Informativi Geografici svoltosi a Potenza e conclusosi ieri,
mi sono occupato e continuo tuttora ad occuparmi di trasformazioni di
dati catastali nei vari sistemi cartografici. In particolare, ho
sviluppato il modello DBlink per ottenere la pseudo-congruenza tra DB
catastale e DB topografico, presentato ad ASITA 2006 e recentemente
oggetto di attenzione della rivista Geomedia (n° 4/2007). Inoltre,
recentemente ho creato un convertitore di coordinate catastali in
Gauss-Boaga Roma40 che fornisce risultati molto accurati. A breve
studierò il modo di applicare tale conversione ad interi set di dati
(es. foglio) in funzione del suo specifico formato.
A tal proposito, sono d'accordo con Andrea: la trasformazione,
altera la geometria dei dati ufficiali e quindi,
per ottenere la tanto desiderata sovrapposizione con la CTR, sarebbe
auspicabile semplicemente una buona proiezione al volo, lasciando
inalterata la geometria del DB originale, tutto ciò anche nell'ottica
dei periodici aggiornamenti. (ricordo una conversazione con Piergiorgio
Cipriano al master in tal senso... si parlava di CDU :wink: )
Esistono svariate metodologie, più o meno approssimate, ma in ogni caso
il rubbersheet è assolutamente da evitare, così come anche raccomandato
dal Gruppo di lavoro dell'Area 5 di IntesaGIS.

Ciao
Antonio

Ciao Luca,

ho notato questo post tuo

http://www.nabble.com/Italian-Catastal-System-tf1367878.html#a3668241

e mi sembra che tu abbia gia' fatto (quasi?) tutto il lavoro
aggiungendo supporto per il sistema catastale italiano a Proj.4

Non avresti un esempio pronto su come trasformare coordinate dal catasto
a GaussBoaga usando proj.4? Devo sapere le coordinate del Origine di
Cassini Soldner oppure e' aggiunto anche quello? E' documentato
qualche parte come esprimere il sistema catastale come SRS?

Sarebbe possibile metterlo su http://spatialreference.org/?

mille grazie
-b

ciao Antonio,

Bud ti ringrazio davvero per aver sollevato queste problematiche in
lista. Davvero interessante questo post!

Provo di aiutare me stesso :wink:

Personalmente, per esigenze lavorative ed in concomitanza con un master
in Sistemi Informativi Geografici svoltosi a Potenza e conclusosi ieri,

congratulazioni

mi sono occupato e continuo tuttora ad occuparmi di trasformazioni di
dati catastali nei vari sistemi cartografici. In particolare, ho
sviluppato il modello DBlink per ottenere la pseudo-congruenza tra DB
catastale e DB topografico, presentato ad ASITA 2006 e recentemente
oggetto di attenzione della rivista Geomedia (n° 4/2007).

Molto interessante. Ho provato di trovare qualcosa in rete ma non sono
riuscito. Potresti mandare un link alle tue presentazioni?

Inoltre,
recentemente ho creato un convertitore di coordinate catastali in
Gauss-Boaga Roma40 che fornisce risultati molto accurati. A breve
studierò il modo di applicare tale conversione ad interi set di dati
(es. foglio) in funzione del suo specifico formato.

Mi imagino che essendo su questa lista lo sviluppi sotto licenza open
source? Sara' integrato con proj.4/OGR..?

A tal proposito, sono d'accordo con Andrea: la trasformazione,
altera la geometria dei dati ufficiali e quindi,
per ottenere la tanto desiderata sovrapposizione con la CTR, sarebbe
auspicabile semplicemente una buona proiezione al volo, lasciando
inalterata la geometria del DB originale, tutto ciò anche nell'ottica
dei periodici aggiornamenti.

Se e' veloce perche' no..

(ricordo una conversazione con Piergiorgio
Cipriano al master in tal senso... si parlava di CDU :wink: )

CDU?

Esistono svariate metodologie, più o meno approssimate, ma in ogni caso
il rubbersheet è assolutamente da evitare, così come anche raccomandato
dal Gruppo di lavoro dell'Area 5 di IntesaGIS.

Benissimo, giusto che ho cercato: la best practice. Hai un link alle
raccomendazioni? Ho trovato alcuni articoli in rete ma penso che ci
possa essere qualcosa migliore.

Forse possiamo poi raccogliere anche links a questi documenti sul wiki..

mille grazie per l'input

-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@comune.grosseto.it
Comune di Grosseto jabber: bud@jabber.no
Via Ginori, 43 http://www.comune.grosseto.it/
58100 Grosseto (Tuscany, Italy)
http://www.comune.grosseto.it/interopEID/