[Gfoss] Collezione script per CTRN Friuli Venezia Giulia

salvaste · December 15, 2008, 9:31pm

Salve a tutti,

scusate il cross-posting ma penso che questo interessi entrambe le liste.

ho collezionato e integrato un po’ di script per manipolare la Carta Tecnica del FVG, ringrazio gli autori originali (Christian Pellegrin e Niccolo Rigacci) per averli messi a disposizione.

Per ora sono solo per la versione 1:5000.

Il risultato degli script è quello di avere uno shape file per ogni classe della carta tecnica sia in Gauss Boaga che in WGS84.

gli script sono i seguenti (elencati nell’ordine in cui andrebbero eseguiti)

downloader.sh - è una versione lievemente modificata dello script di Niccolo per scaricare tutti i file FCN dal sito della regione
rinomina.sh - questo file viene creato dal precedente per sistemare alcune incongruenze nella nomenclatura dei file

ctrn2shp.sh - esegue su tutti i file scaricati lo script seguente
(fcn2shp.py) - è una versione semplificata degli script di Christian che converte il formato FCN in SHP, la proiezione è sempre Gauss Boaga

mergeshp.sh - layer per layer crea uno shape relativo a tutta la regione (sempre in Gauss Boaga)

reproject.sh - riproietta i file prodotti dallo script precedente in WGS84

in conclusione la catena degli script è la seguente:

downloader.sh
rinomina.sh
ctrn2shp.sh
mergeshp.sh
reproject.sh

e alla fine verranno prodotte le seguenti cartelle:

FCN - contiene i file originali scaricati dal sito della regione
shapes - contiene i file shp convertiti (una cartella per ogni tavoletta)
merged/GaussBoaga - contiene i file shp fusi assieme (uno shape per ogni classe)
merged/WGS84 - come sopra ma in WGS84

i requisiti sono:

Linux
GDAL compilato con i bindings per Python
una decina di GB di spazio disco
qualche ora di pazienza

quel che resta da fare è importare gli shape in PostGIS e produrre una configurazione per GeoServer in modo da mettere in piedi un servizio WMS utilizzabile da JOSM (o qualsiasi altro programma preferiate)

Ciao,

Stefano

CTRN_scripts.tar.gz (4.74 KB)

Francesco_Pirotti · December 16, 2008, 7:17am

Ciao Stefano,

COme viene trasformato lo shapefile da Gauss Boaga in WGS84 senza perdere di precisione? In teoria per rimanere all'interno della tolleranza della carta in scala 1:10000 l'errore della trasformazione non deve portare gli elementi nella mia carta ad avere differenze maggiori di 3 m rispetto ad eventuali punti di controllo. Solitamente questo viene fatto utilizzando i grigliati dell'IGM oppure si trasforma "sopportando gli errori".

Ciao

--------------------------------------
Francesco Pirotti
Dept. Te.S.A.F./CIRGEO
University of Padua
Viale dell'Università 16
I-35020 Legnaro (PD)
tel. +39 049 827 2710
fax. +39 049 827 2686
mob. +39 349 55 39 361
@mail francesco.pirotti@unipd.it
skypeID francesco197576
http://www.cirgeo.unipd.it/cirgeo/francescopirotti.htm

---------- Original Message ----------
To: openstreetmap list - italiano (talk-it@openstreetmap.org)
From: Stefano Salvador (stefano.salvador@gmail.com)
Subject: [Gfoss] Collezione script per CTRN Friuli Venezia Giulia
Date: 15/12/2008 22:31:28

Salve a tutti,

scusate il cross-posting ma penso che questo interessi entrambe le liste.

ho collezionato e integrato un po' di script per manipolare la Carta Tecnica del FVG, ringrazio gli autori originali (Christian Pellegrin e Niccolo Rigacci) per averli messi a disposizione.

Per ora sono solo per la versione 1:5000.

Il risultato degli script è quello di avere uno shape file per ogni classe della carta tecnica sia in Gauss Boaga che in WGS84.

gli script sono i seguenti (elencati nell'ordine in cui andrebbero eseguiti)

downloader.sh - è una versione lievemente modificata dello script di Niccolo per scaricare tutti i file FCN dal sito della regione
rinomina.sh - questo file viene creato dal precedente per sistemare alcune incongruenze nella nomenclatura dei file

ctrn2shp.sh - esegue su tutti i file scaricati lo script seguente
(fcn2shp.py) - è una versione semplificata degli script di Christian che converte il formato FCN in SHP, la proiezione è sempre Gauss Boaga

mergeshp.sh - layer per layer crea uno shape relativo a tutta la regione (sempre in Gauss Boaga)

reproject.sh - riproietta i file prodotti dallo script precedente in WGS84

in conclusione la catena degli script è la seguente:

downloader.sh
rinomina.sh
ctrn2shp.sh
mergeshp.sh
reproject.sh

e alla fine verranno prodotte le seguenti cartelle:

FCN - contiene i file originali scaricati dal sito della regione
shapes - contiene i file shp convertiti (una cartella per ogni tavoletta)
merged/GaussBoaga - contiene i file shp fusi assieme (uno shape per ogni classe)
merged/WGS84 - come sopra ma in WGS84

i requisiti sono:

- Linux
- GDAL compilato con i bindings per Python
- una decina di GB di spazio disco
- qualche ora di pazienza

quel che resta da fare è importare gli shape in PostGIS e produrre una configurazione per GeoServer in modo da mettere in piedi un servizio WMS utilizzabile da JOSM (o qualsiasi altro programma preferiate)

Ciao,

Stefano

Paolo_Craveri · December 17, 2008, 7:23pm

ciao.

2008/12/16 francesco <francesco.pirotti@unipd.it>:

Ciao Stefano,

COme viene trasformato lo shapefile da Gauss Boaga in WGS84 senza perdere di precisione? In teoria per rimanere all'interno della tolleranza della carta in scala 1:10000 l'errore della trasformazione non deve portare gli elementi nella mia carta ad avere differenze maggiori di 3 m rispetto ad eventuali punti di controllo. Solitamente questo viene fatto utilizzando i grigliati dell'IGM oppure si trasforma "sopportando gli errori".

Al di là delle considerazioni circa la "natura ambigua" del software
(free,open,proprietario, proibito, permesso, quasi-libero, ecc..
ecc..), cosa ne pensi di traspunto ?

Non ho fatto prove rigorose ma mi sembra (almeno per la regione ove
opero, il Piemonte) che dia risultati migliori rispetto a ogr2ogr
usato con codice epsg+towgs. (sia da ed50 32N che da roma40 fuso O
verso wgs84 32N).

Esistono per caso prove rigorose di confronto con una serie di punti noti?

ciao

--
--
Paolo C.
Lat. 44° 39' 11.08'' N Long. 7° 23' 25.26'' E

salvaste · December 18, 2008, 9:00am

Al di là delle considerazioni circa la “natura ambigua” del software
(free,open,proprietario, proibito, permesso, quasi-libero, ecc…
ecc…), cosa ne pensi di traspunto ?

Non ho fatto prove rigorose ma mi sembra (almeno per la regione ove
opero, il Piemonte) che dia risultati migliori rispetto a ogr2ogr
usato con codice epsg+towgs. (sia da ed50 32N che da roma40 fuso O
verso wgs84 32N).

Esistono per caso prove rigorose di confronto con una serie di punti noti?

mi sono un po’ documentato e ho trovato questo articolo che però purtroppo non parla di ogr2ogr:

http://www.sisef.it/forest@/pdf/Travaglini_228.pdf

pare che traspunto sia quello che da i risultati migliori, ha il difetto di non avere una licenza, soprattutto per i dati prodotti (per lo meno io non l’ho trovata).

ci vorrebbe un articolo simile al precedente (magari con qualche numero in più …) che consideri anche gli strumenti opensource. Leggendo in giro comunque ho l’impressione che l’errore è compatibile con qualsiasi misura gps quindi per i fini di osm ogr2ogr penso vada più che bene.

detto questo sapete se esiste qualche iniziativa per stimolare l’igm a liberare le sue griglie di conversione? è assurdo che si debba pagare decine di euro per avere 7 numeri (che poi non posso divulgare in nessun modo, rendondo difficile il confronto dei dati con altre persone)

Ciao,

Stefano

Cristoforo_Abbattist · December 18, 2008, 9:53am

ci vorrebbe un articolo simile al precedente (magari con qualche numero in più ...) che consideri anche gli strumenti opensource. Leggendo in giro comunque ho l'impressione che l'errore è compatibile con qualsiasi misura gps quindi per i fini di osm ogr2ogr penso vada più che bene.

in realtà se ogr usa Molodensky (e penso che lo usi), un cambio di datum può introdurre fino a 150 metri di errore.

Quindi nel digitale si potrebbe andar bene in mappe fino a 300 m/px; se stampate, fino a mappe 1:300.000.

Potrei aver fatto qualche errore di calcolo o assunzioni non condivise, ma gli ordini di grandezza sono quelli. Ossia "GPS incompatibili". Poi si può essere pure fortunati ed avere un errore nullo.

Ciao
Cristoforo

Luca_Manganelli2 · December 18, 2008, 9:56am

Stefano Salvador ha scritto:

mi sono un po' documentato e ho trovato questo articolo che però purtroppo non parla di ogr2ogr:

http://www.sisef.it/forest@/pdf/Travaglini_228.pdf

pare che traspunto sia quello che da i risultati migliori, ha il difetto di non avere una licenza, soprattutto per i dati prodotti (per lo meno io non l'ho trovata).

ci vorrebbe un articolo simile al precedente (magari con qualche numero in più ...) che consideri anche gli strumenti opensource. Leggendo in giro comunque ho l'impressione che l'errore è compatibile con qualsiasi misura gps quindi per i fini di osm ogr2ogr penso vada più che bene.

detto questo sapete se esiste qualche iniziativa per stimolare l'igm a liberare le sue griglie di conversione? è assurdo che si debba pagare decine di euro per avere 7 numeri (che poi non posso divulgare in nessun modo, rendondo difficile il confronto dei dati con altre persone)

Quindi in teoria non è possibile usare OGR2OGR per fare le conversioni da Gauss Boaga a WGS84?

Simone_Cortesi · December 20, 2008, 11:53am

On Thu, Dec 18, 2008 at 10:56 AM, Luca Manganelli
<luca_manganelli@comune.trento.it> wrote:

detto questo sapete se esiste qualche iniziativa per stimolare l'igm a
liberare le sue griglie di conversione? è assurdo che si debba pagare decine
di euro per avere 7 numeri (che poi non posso divulgare in nessun modo,
rendondo difficile il confronto dei dati con altre persone)

Quindi in teoria non è possibile usare OGR2OGR per fare le conversioni da
Gauss Boaga a WGS84?

per quanto di ho capito io le uniche conversioni Gauss-Boaga <-->
WGS84, esatte, precise, certificabili sono quelle eseguite da Verto,
il software dell'Istituto geografico della marina.

tutte le altre conversioni (ogr, esri), per pur buone che siano, non
posso essere precise come quelle fatte con Verto.

sbaglio?

-S