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 _______________________________________________ [hidden email] 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
Claudio Rocchini
www.rockini.name |
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 ;) 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 _______________________________________________ [hidden email] 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 |
In reply to this post by rockini
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 _______________________________________________ [hidden email] 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 |
In reply to this post by rockini
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"... :) |
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 <[hidden email]> ha scritto: / Giovanni Allegri http://about.me/giovanniallegri Gis3W - http://gis3w.it _______________________________________________ [hidden email] 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 |
In reply to this post by Sieradz
On Thu, 15 Oct 2015 02:42:48 -0700 (MST)
Sieradz <[hidden email]> 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"... > > :) 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 <[hidden email]> Firenze, via di Novoli 26 055 4383194 _______________________________________________ [hidden email] 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 |
...otterra' sempre e soltanto un KML in EPSG:4326, pertanto non andrebbe inserito come formato di input nel convertitore IGM, imho... :) |
On Thu, 15 Oct 2015 08:24:10 -0700 (MST)
Sieradz <[hidden email]> 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... > > :) > 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 <[hidden email]> Firenze, via di Novoli 26 055 4383194 _______________________________________________ [hidden email] 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 |
In reply to this post by rockini
On Thu, Oct 15, 2015 at 11:17 AM, Claudio Rocchini <[hidden email]> 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 _______________________________________________ [hidden email] 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 |
On Fri, 16 Oct 2015 11:39:01 +0200
Amedeo Fadini <[hidden email]> 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 <[hidden email]> Firenze, via di Novoli 26 055 4383194 _______________________________________________ [hidden email] 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 |
In reply to this post by rockini
Salve, A. Il 15 ott 2015 11:24, "Claudio Rocchini" <[hidden email]> ha scritto:
_______________________________________________ [hidden email] 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 |
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... |
In reply to this post by Andrea Peri
Esiste un bugtracker del progetto?
Saluti. Il 16 ottobre 2015 12:46:51 CEST, Andrea Peri <[hidden email]> ha scritto:
-- Paolo Cavallini http://www.faunalia.eu _______________________________________________ [hidden email] 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 |
In reply to this post by Sieradz
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 <[hidden email]> 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. > _______________________________________________ > [hidden email] > 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 àèìòù ----------------- _______________________________________________ [hidden email] 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 |
In reply to this post by Andrea Peri
Salve Andrea,
Infatti, caricando il file in output dal servizio, per esempio in QGIS, gli oggetti trasformati vanno a finire... nell'iperspazio. :( 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 _______________________________________________ [hidden email] 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 |
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, <[hidden email]> 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. :( > > 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 àèìòù ----------------- _______________________________________________ [hidden email] 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 |
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 :) |
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 <[hidden email]> 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 :) > > > > -- > 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. > _______________________________________________ > [hidden email] > 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 àèìòù ----------------- _______________________________________________ [hidden email] 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 |
In reply to this post by Andrea Peri
Andrea,
> Il giorno 16/ott/2015, alle ore 14:11, Andrea Peri <[hidden email]> 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. :( 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 ? :) Ok, abbiamo fatto un primo passo verso l'OpenData. A presto Roberto _______________________________________________ [hidden email] 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 |
Free forum by Nabble | Edit this page |