[Gfoss] Verto On-line dell'IGM

Sul sito dell’Istituto Geografico Militare è stata pubblicata la versione on-line di Verto (conversione di coordinate) con accesso gratuito.
Ecco gli indirizzi relativi:

Convertitore di files:
http://www.igmi.org/vol/index_file.php

Convertitore di coordinate singole:
http://www.igmi.org/vol/index_coord.php


Claudio Rocchini

Il 15/10/2015 11:17, Claudio Rocchini ha scritto:

Sul sito dell'Istituto Geografico Militare è stata pubblicata la
versione on-line di Verto (conversione di coordinate) con accesso gratuito.
Ecco gli indirizzi relativi:

Convertitore di files:
http://www.igmi.org/vol/index_file.php

Convertitore di coordinate singole:
http://www.igmi.org/vol/index_coord.php

Grazie - vedo che la segnalazione non e' casuale :wink:

Conversione Fallita
ERROR 4: Unable to open
/home/rocchini/vol/wps/1bf1dc84c6c455ba221d789b40e006e9/f1.shx or
/home/rocchini/vol/wps/1bf1dc84c6c455ba221d789b40e006e9/f1.SHX.
FAILURE:
Unable to open datasource
`/home/rocchini/vol/wps/1bf1dc84c6c455ba221d789b40e006e9/f1.shp' with
the following drivers.

nello specifico, l'errore pare dovuto alla necessita' di inviare lo zip,
riprovo.
Saluti, e grazie!
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html

Il 15/10/2015 11:17, Claudio Rocchini ha scritto:

Sul sito dell'Istituto Geografico Militare è stata pubblicata la
versione on-line di Verto (conversione di coordinate) con accesso gratuito.
Ecco gli indirizzi relativi:

Convertitore di files:
http://www.igmi.org/vol/index_file.php

Convertitore di coordinate singole:
http://www.igmi.org/vol/index_coord.php

Altro problema: se genero un file con EPSG:25832, il prj risultante non
viene compreso da QGIS.
Saluti.

--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html

/
rockini wrote

Sul sito dell'Istituto Geografico Militare è stata pubblicata la versione
on-line di Verto (conversione di coordinate) con accesso gratuito

/
Grazie per l'info, ma segnalo sommessamente che il formato KML è unicamente
in EPSG:4326 quindi andrebbe in conflitto con un eventuale errato "Sistema
Rif. in ingresso"...

:slight_smile:

--
View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Verto-On-line-dell-IGM-tp7594552p7594555.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.

Questa nota può tornare utile per utilizzare correttamente lo strumento: http://host154-194-static.207-37-b.business.telecomitalia.it/epsg/NotaSistemiEPSG.pdf

giovanni

···

Il giorno 15 ottobre 2015 11:42, Sieradz <antonio@amicocad.it> ha scritto:

/
rockini wrote

Sul sito dell’Istituto Geografico Militare è stata pubblicata la versione
on-line di Verto (conversione di coordinate) con accesso gratuito

/
Grazie per l’info, ma segnalo sommessamente che il formato KML è unicamente
in EPSG:4326 quindi andrebbe in conflitto con un eventuale errato “Sistema
Rif. in ingresso”…

:slight_smile:


View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Verto-On-line-dell-IGM-tp7594552p7594555.html
Sent from the Gfoss – Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.


Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell’Associazione GFOSS.it.
786 iscritti al 30.9.2015

Giovanni Allegri
http://about.me/giovanniallegri
Gis3W - http://gis3w.it
Ikare - http://ikare.it

Twitter: https://twitter.com/giohappy
blog: http://blog.spaziogis.it
GEO+ geomatica in Italia http://bit.ly/GEOplus

On Thu, 15 Oct 2015 02:42:48 -0700 (MST)
Sieradz <antonio@amicocad.it> wrote:

/
rockini wrote
> Sul sito dell'Istituto Geografico Militare è stata pubblicata la versione
> on-line di Verto (conversione di coordinate) con accesso gratuito

/
Grazie per l'info, ma segnalo sommessamente che il formato KML è unicamente
in EPSG:4326 quindi andrebbe in conflitto con un eventuale errato "Sistema
Rif. in ingresso"...

:slight_smile:

molto probabilmente il kml contiene dati che, per la loro intrinseca precisione, possono essere convertiti con altri sistemi "più blandi".
le conversioni che propone IGM sono per dati geodetici/topografici frutto di rilievi inquadrati su una rete geodetica italiana, quindi mi pare sensato non accettare dati inquadrati su sistemi non esistenti in italia.
se poi uno ha fatto un rilievo appoggiato alla rete geodetica italiana e lo registra nel formato kml... penso che basti dire al convertitore il sistema giusto.
ovvero: l'abito non fa il monaco, oppure dire kml non vuol dire 4326.
imho
marco

--
Marco Guiducci <marco.guiducci@regione.toscana.it>
Firenze, via di Novoli 26
055 4383194

/
Marco Guiducci-3 wrote

se poi uno ha fatto un rilievo appoggiato alla rete geodetica italiana e
lo registra nel formato kml...

/

...otterra' sempre e soltanto un KML in EPSG:4326, pertanto non andrebbe
inserito come formato di input nel convertitore IGM, imho...

:slight_smile:

--
View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Verto-On-line-dell-IGM-tp7594552p7594562.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.

On Thu, 15 Oct 2015 08:24:10 -0700 (MST)
Sieradz <antonio@amicocad.it> wrote:

/
Marco Guiducci-3 wrote
> se poi uno ha fatto un rilievo appoggiato alla rete geodetica italiana e
> lo registra nel formato kml...

/

...otterra' sempre e soltanto un KML in EPSG:4326, pertanto non andrebbe
inserito come formato di input nel convertitore IGM, imho...

:slight_smile:

dipende da chi scrive il kml. se lo fai fare a QGis, nella finestra esporta gli puoi scrivere in sr a caso, ma lui usa il 4326.
se te lo scrivi a manina (o con una buona macro) il kml, ci metti i numeri che vuoi. Igm interpreta i numeri solo in base a quello che si scrive nella form.
ma si torna lì: se si vuole traslocare un rilievo, ripeto, inquadrato su una rete geodetica italiana, per vederlo in Google-qualcosa allora va bene QGis senza grigliati.
Se si vuole usare per forza il formato kml per portare dati "buoni" da altre parti si può fare come ho detto. Altrimenti: altri formati di scambio.
quindi: kml potrebbe essere un formato di scambio se.... altrimenti concordo con te: meglio levarlo dalla lista.

--
Marco Guiducci <marco.guiducci@regione.toscana.it>
Firenze, via di Novoli 26
055 4383194

On Thu, Oct 15, 2015 at 11:17 AM, Claudio Rocchini <claudio@rockini.name> wrote:

Sul sito dell'Istituto Geografico Militare è stata pubblicata la versione
on-line di Verto (conversione di coordinate) con accesso gratuito.
Ecco gli indirizzi relativi:

Convertitore di files:
http://www.igmi.org/vol/index_file.php

Grazie per la segnalazione, mi pare un ottimo strumento, realizzato
con software e sistema operativo Open Source a quanto si vede dai
loghi e dai messaggi di errore.
Complimenti.

Alcune considerazioni a titolo puramente personale:
Conoscendo le tradizioni della PA immagino che la realizzazione di
questo strumento non sia stata accompagnata da un finanziamento
corrispondente ai progetti open source che sono stati utilizzati... mi sbaglio?.

Sarebbe utile conoscere una descrizione dell'architettura se è già
stata presentata.

Il captcha sta a significare che non sarà mai possibile convertire più
di UN livello alla volta?
Nemmeno su prenotazione (ad esempio un piano urbanistico o una V.I.A.
da consegnare a una
pubblica amministrazione)?
C'è forse l'intenzione di offrire una API-key o una login per quegli
utenti che si trovano a convertire molti file e non hanno diritto ad
avere i grigliati gratuitamente?

amefad

On Fri, 16 Oct 2015 11:39:01 +0200
Amedeo Fadini <fame@libero.it> wrote:

Il captcha sta a significare che non sarà mai possibile convertire più
di UN livello alla volta?

c'è scritto che se si deve convertire più file, occorre zipparli insieme.
però non mi pare ci sia scritto il numero massimo di file.
(ovviamente file omogenei per coordinate)

--
Marco Guiducci <marco.guiducci@regione.toscana.it>
Firenze, via di Novoli 26
055 4383194

Salve,
noto che nel file prj che genera viene inserita una extension che punta verso una cartella che è probabilmente locale sul tuo server per indicare ilnparametro nadgrid e la cartella locale dove sono i grigliati igm.
Non sono esperto del formato prj, ma questa porzione della definizione potrebbe comportare qualche problema sul.client che lo impiega. Se tentasse di rintracciare localmente questa cartella inesistente.
Potrebbe essere il caso di rimuoverla quella porzione di definizione ?
Però non so se è essenziale.per dare.senso alla definizione del.sistema di riferimento del dataset o se serve solamente in fase di conversione

A.

Il 15 ott 2015 11:24, “Claudio Rocchini” <claudio@rockini.name> ha scritto:

Sul sito dell’Istituto Geografico Militare è stata pubblicata la versione on-line di Verto (conversione di coordinate) con accesso gratuito.
Ecco gli indirizzi relativi:

Convertitore di files:
http://www.igmi.org/vol/index_file.php

Convertitore di coordinate singole:
http://www.igmi.org/vol/index_coord.php


Claudio Rocchini


Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell’Associazione GFOSS.it.
786 iscritti al 30.9.2015

/
Andrea Peri wrote

Potrebbe essere il caso di rimuoverla quella porzione di definizione ?

/

Dopo la segnalazione di Paolo, è stata la prima cosa che ho fatto ieri, ma
pur eliminandola il .PRJ viene ignorato, sia da Qgis che da GM...

--
View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Verto-On-line-dell-IGM-tp7594552p7594573.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.

Esiste un bugtracker del progetto?
Saluti.

Il 16 ottobre 2015 12:46:51 CEST, Andrea Peri aperi2007@gmail.com ha scritto:

Salve,
noto che nel file prj che genera viene inserita una extension che punta verso una cartella che è probabilmente locale sul tuo server per indicare ilnparametro nadgrid e la cartella locale dove sono i grigliati igm.
Non sono esperto del formato prj, ma questa porzione della definizione potrebbe comportare qualche problema sul.client che lo impiega. Se tentasse di rintracciare localmente questa cartella inesistente.
Potrebbe essere il caso di rimuoverla quella porzione di definizione ?
Però non so se è essenziale.per dare.senso alla definizione del.sistema di riferimento del dataset o se serve solamente in fase di conversione

A.

Il 15 ott 2015 11:24, “Claudio Rocchini” <claudio@rockini.name> ha scritto:

Sul sito dell’Istituto Geografico Militare è stata pubblicata la versione on-line di Verto (conversione di coordinate) con accesso gratuito.
Ecco gli indirizzi relativi:

Convertitore di files:
http://www.igmi.org/vol/index_file.php

Convertitore di coordinate singole:
http://www.igmi.org/vol/index_coord.php


Claudio Rocchini


Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e’ una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell’Associazione GFOSS.it.
786 iscritti al 30.9.2015


---

Gfoss@lists.gfoss.it
[http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss](http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss)
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione [GFOSS.it](http://GFOSS.it).
786 iscritti al 30.9.2015


Paolo Cavallini
http://www.faunalia.eu

Premesso che potrei ricordare male.
Mi pareva di ricordare che qgis tentasse sempre di associare il prj a
uno dei sistemi di riferimento nel suo db interno.

Il che se confermato potrebbe spiegare perche' lo ignora.
Infatti probabilmente qualche dettaglio della definizione che qgis usa
per trovare la similitudine con il suo db locale non gli torna.

In ogni caso , se il prj che viene fornito e' corretto dal punto di
vista dello standard prj , il problema sarebbe di qgis non del file
prj.
Questo io non lo so', occorrerebbe essere esperti del formato prj per
stabilire dove sta' l'incomprensione.

Il mio dubbio e' rivolto piuttosto al fatto ce non avevo mai visto un
prj con dentro una sezione EXTENSION .
La cosa e' interessante dal punto di vista tecnico, ma smuove anche
interrogativi.

Infatti in tale sezione e' presente una definizione nadgrid su un path
che indica dove e' il grigliato. E contiene un path locale sul server
dell' IGM.
Mi domandavo se tale porzione della definzione era necessaria pr dare
senso alla intera definizione del prj.
In caso affermativo forse sarebbe stato meglio metterci una stringa
dummy (un namespace).
ci avrebbero potuto scrivere ad esempio:

nadgrid=http://www.igm.it

Sempre da un punto di vista tecnico, su un tale parametro, se in un
futuro i grigliati IGM verranno resi gratuitamente distribuibili ,
ci potra' andare una uri verso dei grigliati accessibli remotamente.

qualcosa del tipo:

+nadgrid=http://www.igm.org/vol/griglie/35160622_47161840_F89_R40.gsb

Ma ad oggi questa cosa non è all'ordine del giorno e quindi torniamo
al fatto che il percorso sul server igm non serve e forse e'
didicevole fornirlo:

+nadgrids=/home/cartella/vol/griglie/35160622_47161840_F89_R40.gsb

A.

Il 16 ottobre 2015 13:00, Sieradz <antonio@amicocad.it> ha scritto:

/
Andrea Peri wrote

Potrebbe essere il caso di rimuoverla quella porzione di definizione ?

/

Dopo la segnalazione di Paolo, è stata la prima cosa che ho fatto ieri, ma
pur eliminandola il .PRJ viene ignorato, sia da Qgis che da GM...

--
View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Verto-On-line-dell-IGM-tp7594552p7594573.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.
_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
786 iscritti al 30.9.2015

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

Salve Andrea,

Salve,
noto che nel file prj che genera viene inserita una extension che punta verso una cartella che è probabilmente locale sul tuo server per indicare ilnparametro nadgrid e la cartella locale dove sono i grigliati igm.
Non sono esperto del formato prj, ma questa porzione della definizione potrebbe comportare qualche problema sul.client che lo impiega.

Infatti, caricando il file in output dal servizio, per esempio in QGIS, gli oggetti trasformati vanno a finire… nell’iperspazio. :frowning:

Per vederli sovrapposti a altri file di controllo, occorre cancellare il file PRJ uscito dal servizio (ovviamente salvandoselo prima con un altro nome) e poi assegnare al file shp di output un PRJ più “standard”, riconoscibile da QGIS (e dagli altri sw che usano GDAL e PROJ4 ).

È un peccato che si debba fare questo, ma tant’è.

Domanda: qualcuno è a conoscenza della data in cui è stato aperto questo servizio di IGM ( peraltro encomiabile, ma dovuto ) ?

Grazie per qualunque info a riguardo.

A presto

Roberto

Questo pero' non implica che il problema sia nel prj generato dal servizio IGM.

Gli elementi di conoscenza che abbiamo al momento non consentono di
escludere che il bug sia su gdal.
Anche perche' qgis usa gdal per accedere gli shapefiles e quindi nulla
aggiunge alla questione.

A.

Il 16 ottobre 2015 13:48, <geodrinx@gmail.com> ha scritto:

Salve Andrea,

Salve,
noto che nel file prj che genera viene inserita una extension che punta
verso una cartella che è probabilmente locale sul tuo server per indicare
ilnparametro nadgrid e la cartella locale dove sono i grigliati igm.
Non sono esperto del formato prj, ma questa porzione della definizione
potrebbe comportare qualche problema sul.client che lo impiega.

Infatti, caricando il file in output dal servizio, per esempio in QGIS, gli
oggetti trasformati vanno a finire... nell'iperspazio. :frowning:

Per vederli sovrapposti a altri file di controllo, occorre cancellare il
file PRJ uscito dal servizio (ovviamente salvandoselo prima con un altro
nome) e poi assegnare al file shp di output un PRJ più "standard",
riconoscibile da QGIS (e dagli altri sw che usano GDAL e PROJ4 ).

È un peccato che si debba fare questo, ma tant'è.

Domanda: qualcuno è a conoscenza della data in cui è stato aperto questo
servizio di IGM ( peraltro encomiabile, ma dovuto ) ?

Grazie per qualunque info a riguardo.

A presto

Roberto

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

/
Andrea Peri wrote

Questo pero' non implica che il problema sia nel prj generato dal servizio
IGM

/

Ultim'ora, soprattutto per il debug di C.Rocchini: allacciatevi le cinture.

Il file PRJ, ripeto, non viene interpetrato nè da Qgis nè dal commerciale
GM, mentre viene perfettamente riconosciuto dal mio primo amore opensource,
ovvero "Mapwindow Gis".

Buon weekend a tutti :slight_smile:

--
View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Verto-On-line-dell-IGM-tp7594552p7594578.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.

Il che rafforza il concetto che forse e'un bug della gdal.

GM: probabilmente non lo conosco, ma forse anche lui fa' uso di gdal ?

A.

Il 16 ottobre 2015 14:53, Sieradz <antonio@amicocad.it> ha scritto:

/
Andrea Peri wrote

Questo pero' non implica che il problema sia nel prj generato dal servizio
IGM

/

Ultim'ora, soprattutto per il debug di C.Rocchini: allacciatevi le cinture.

Il file PRJ, ripeto, non viene interpetrato nè da Qgis nè dal commerciale
GM, mentre viene perfettamente riconosciuto dal mio primo amore opensource,
ovvero "Mapwindow Gis".

Buon weekend a tutti :slight_smile:

--
View this message in context: http://gfoss-geographic-free-and-open-source-software-italian-mailing.3056002.n2.nabble.com/Verto-On-line-dell-IGM-tp7594552p7594578.html
Sent from the Gfoss -- Geographic Free and Open Source Software - Italian mailing list mailing list archive at Nabble.com.
_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
786 iscritti al 30.9.2015

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

Andrea,

Il giorno 16/ott/2015, alle ore 14:11, Andrea Peri <aperi2007@gmail.com> ha scritto:

Questo pero' non implica che il problema sia nel prj generato dal servizio IGM.

Gli elementi di conoscenza che abbiamo al momento non consentono di
escludere che il bug sia su gdal.
Anche perche' qgis usa gdal per accedere gli shapefiles e quindi nulla
aggiunge alla questione.

Certo. Infatti non intendevo dare "colpe" a nessuno. Volevo soltanto testimoniare uno stato di fatto, e una soluzione per risolvere, speriamo solo oggi, il problema. Diciamo che non è bello che si ottengano coordinate precisissime ( a proposito, qualcuno può indicarci quanto precise, o approssimate o il termine più adatto... ) e non è bello che poi, per qualche dettaglio tecnico, non si possa apprezzare questa impressionante precisione. :frowning:

Quindi, ho indicato un metodo, buono spero solo per oggi ( perchè domani avranno sicuramente risolto il problema ) , per visualizzare i file trasformati sul luogo reale, in QGIS, per confrontarlo con dei dato di confronto, come possono essere i confini dei comuni forniti da ISTAT.

Avete già verificato ? Cosa vi risulta ? Bello ?

:slight_smile:

Ok, abbiamo fatto un primo passo verso l'OpenData.

A presto

Roberto