forse è un problema banalissimo e farò la figura del cioccolataio, ma lavorando ieri notte (complice la stanchezza!) le misure prorpio non mi tornavano.
Dovevo calcolare la lunghezza complessiva delle linee che ricadono nei vari poligoni, utilizzando l’apposita funzione di fTools.
Successivamente ho fatto un controllo a campione con lo strumento di misurazione delle distanze e …non erano le stesse!
Ho controllato sia stata impostata la misura in metri, che tutte le feature fossero nel medesimo CRS, prima in EPSG:4326 - WGS 84 poi facendo una prova anche con il EPSG:3857 - WGS84/pseudo mercator ed infine ho anche provato ad impostare vari ellissoidi.
Non ho mai trovato corrispondenza tra la misura fornita dal tool e quella ottenuta con il misuratore di distanze. A questo punto ho alcune domande e spero che qualcuno m’illumini!
Chi dice il vero (tra il tool e il misuratore)?
Come ci si comporta, in generale, quando sono richiesti valori di lunghezze e/o aree ‘assolute’?
Come s’imposta, in fase di digitalizzazione, una lunghezza e/o direzione predefinita per una linea?
il misuratore lavora sulla canvas che e’ riproiettata automaticamente (opzione di default)
ftool (immagino da processing) lavora sul file e dunque sui dati cosi’ come sono… questo potrebbe creare unpo di confusione.
del resto processinglo dice chiaro e tondo… assume che tutto cio’ che analizza sia sottolo stesso crs e non fa conversioni di sorta (a meno di farlo esplicitamente nel workflow)
partire dal capire il crs dei tuoi dati … qual’e’?
forse è un problema banalissimo e farò la figura del cioccolataio, ma lavorando ieri notte (complice la stanchezza!) le misure prorpio non mi tornavano.
Dovevo calcolare la lunghezza complessiva delle linee che ricadono nei vari poligoni, utilizzando l’apposita funzione di fTools.
Successivamente ho fatto un controllo a campione con lo strumento di misurazione delle distanze e …non erano le stesse!
Ho controllato sia stata impostata la misura in metri, che tutte le feature fossero nel medesimo CRS, prima in EPSG:4326 - WGS 84 poi facendo una prova anche con il EPSG:3857 - WGS84/pseudo mercator ed infine ho anche provato ad impostare vari ellissoidi.
Non ho mai trovato corrispondenza tra la misura fornita dal tool e quella ottenuta con il misuratore di distanze. A questo punto ho alcune domande e spero che qualcuno m’illumini!
Chi dice il vero (tra il tool e il misuratore)?
Come ci si comporta, in generale, quando sono richiesti valori di lunghezze e/o aree ‘assolute’?
Come s’imposta, in fase di digitalizzazione, una lunghezza e/o direzione predefinita per una linea?
Il giorno 01 ottobre 2013 10:31, Gino Pirelli <luipir@gmail.com> ha scritto:
la butto li...
il misuratore lavora sulla canvas che e' riproiettata automaticamente
(opzione di default)
ftool (immagino da processing) lavora sul file e dunque sui dati cosi'
come sono... questo potrebbe creare unpo di confusione.
del resto processinglo dice chiaro e tondo... assume che tutto cio' che
analizza sia sottolo stesso crs e non fa conversioni di sorta (a meno di
farlo esplicitamente nel workflow)
partire dal capire il crs dei tuoi dati ... qual'e'?
Ciao a tutti,
forse è un problema banalissimo e farò la figura del cioccolataio, ma
lavorando ieri notte (complice la stanchezza!) le misure prorpio non mi
tornavano.
Dovevo calcolare la lunghezza complessiva delle linee che ricadono nei
vari poligoni, utilizzando l'apposita funzione di fTools.
Successivamente ho fatto un controllo a campione con lo strumento di
misurazione delle distanze e ..non erano le stesse!
Ho controllato sia stata impostata la misura in metri, che tutte le
feature fossero nel medesimo CRS, prima in
EPSG:4326 - WGS 84 poi facendo una prova anche con il EPSG:3857 -
WGS84/pseudo mercator ed infine ho anche provato ad impostare vari
ellissoidi.
Non ho mai trovato corrispondenza tra la misura fornita dal tool e quella
ottenuta con il misuratore di distanze. A questo punto ho alcune domande e
spero che qualcuno m'illumini!
Chi dice il vero (tra il tool e il misuratore)?
Come ci si comporta, in generale, quando sono richiesti valori di
lunghezze e/o aree 'assolute'?
Come s'imposta, in fase di digitalizzazione, una lunghezza e/o
direzione predefinita per una linea?
Un saluto alla lista e grazie,
Daniele
PS: ho QGIS 2.0 su Ubuntu 12.04
_______________________________________________
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.
666 iscritti al 22.7.2013
--
_____________________________
Daniele Bonaposta,
Cartografia - G.I.S.
via Don Minzoni 13a
40121 - Bologna
mobile: +39.338.3377044
e-mail: daniele.bonaposta@gmail.com
Ciao Daniele,
hai verificato i settaggi nelle proprietà del progetto → Generale → Strumento di misura che l’ellissoide sia impostato correttamente?
Controlla anche che la riproiezione sia disattivata…
Il giorno 01 ottobre 2013 10:31, Gino Pirelli <luipir@gmail.com> ha scritto:
la butto li…
il misuratore lavora sulla canvas che e’ riproiettata automaticamente (opzione di default)
ftool (immagino da processing) lavora sul file e dunque sui dati cosi’ come sono… questo potrebbe creare unpo di confusione.
del resto processinglo dice chiaro e tondo… assume che tutto cio’ che analizza sia sottolo stesso crs e non fa conversioni di sorta (a meno di farlo esplicitamente nel workflow)
partire dal capire il crs dei tuoi dati … qual’e’?
forse è un problema banalissimo e farò la figura del cioccolataio, ma lavorando ieri notte (complice la stanchezza!) le misure prorpio non mi tornavano.
Dovevo calcolare la lunghezza complessiva delle linee che ricadono nei vari poligoni, utilizzando l’apposita funzione di fTools.
Successivamente ho fatto un controllo a campione con lo strumento di misurazione delle distanze e …non erano le stesse!
Ho controllato sia stata impostata la misura in metri, che tutte le feature fossero nel medesimo CRS, prima in
EPSG:4326 - WGS 84 poi facendo una prova anche con il EPSG:3857 - WGS84/pseudo mercator ed infine ho anche provato ad impostare vari ellissoidi.
Non ho mai trovato corrispondenza tra la misura fornita dal tool e quella ottenuta con il misuratore di distanze. A questo punto ho alcune domande e spero che qualcuno m’illumini!
Chi dice il vero (tra il tool e il misuratore)?
Come ci si comporta, in generale, quando sono richiesti valori di lunghezze e/o aree ‘assolute’?
Come s’imposta, in fase di digitalizzazione, una lunghezza e/o direzione predefinita per una linea?
forse è un problema banalissimo e farò la figura del cioccolataio, ma lavorando ieri notte (complice la stanchezza!) le misure prorpio non mi tornavano.
Dovevo calcolare la lunghezza complessiva delle linee che ricadono nei vari poligoni, utilizzando l’apposita funzione di fTools.
Successivamente ho fatto un controllo a campione con lo strumento di misurazione delle distanze e …non erano le stesse!
Ho controllato sia stata impostata la misura in metri, che tutte le feature fossero nel medesimo CRS, prima in EPSG:4326 - WGS 84 poi facendo una prova anche con il EPSG:3857 - WGS84/pseudo mercator ed infine ho anche provato ad impostare vari ellissoidi.
Non ho mai trovato corrispondenza tra la misura fornita dal tool e quella ottenuta con il misuratore di distanze. A questo punto ho alcune domande e spero che qualcuno m’illumini!
Chi dice il vero (tra il tool e il misuratore)?
Come ci si comporta, in generale, quando sono richiesti valori di lunghezze e/o aree ‘assolute’?
Come s’imposta, in fase di digitalizzazione, una lunghezza e/o direzione predefinita per una linea?
WGS84 non significa nulla, non essendo un CRS bensì un datum: sotto di lui
si'inquadrano sia CRS a coordinate cartesiane (ad es. UTM) che sferiche
(Lat/Long).
Peraltro EPSG:4326 è un CRS geografico e non cartografico, quindi le misure
sono in gradi/radianti e non in metri.
Purtroppo Qgis non è (ancora) un Cad, quindi non mi risulta tu possa
impostare nè una lunghezza prefissata in fase di digitalizzazione, nè una
direzione tipo "Ortho".
Non ho mai trovato corrispondenza tra la misura fornita dal tool e quella
ottenuta con il misuratore di distanze. A questo punto ho alcune domande e
spero che qualcuno m'illumini!
Chi dice il vero (tra il tool e il misuratore)?
Non so se nel tuo caso sia plausibile, ma esiste una differenza anche
significativa tra misure effettuate su distanza cartesiana, su sfera o
su sferoide e sul sistema di riferimento che si adotta per
riproiettare i dati nell'effettuare i calcoli di distanza.
Ad es su un mio dataset tra Roma e Napoli, usando le funzioni
ST_Distance, ST_DistanceSphere e ST_DistanceSpheroid di PostGIS, ho
rispettivamente una distanza di:
ST_Distance: 191,761 km (riproiettando a UTM 32N)
ST_Distance: 255,388 km (riproiettando a mercator, come fanno tutti i web
gis, valore altamente impreciso!)
ST_DistanceSphere: 191,296 km
ST_DistanceSpheroid: 191,513 km (usando uno spheroid WGS 84)
notare la differenza della riproiezione a mercator!
ciao
Un saluto a tutti e grazie per i vari contributi,
provo a fare un riassunto della situazione:
Ho tutte feature singlepart EPGS:3857, progetto impostato sullo stesso CRS e ho disattivato la riproiezione al volo. In questo modo i valori di fTools e del misuratore coincidono e sembrano plausibili.
Ma poi ho fatto un’altra prova: ho disegnato le linee del campo sportivo (le due linee di fondo, la linea di centrocampo e le due linee laterali) sperando che siano le classiche 105x60, ho lanciato di nuovo fTools, invece di 390m mi dà 557m.
Sono ancora nel limbo: la misura è opinabile?!!
Daniele
···
Il giorno 01 ottobre 2013 22:14, Paolo Corti <pcorti@gmail.com> ha scritto:
Non ho mai trovato corrispondenza tra la misura fornita dal tool e quella
ottenuta con il misuratore di distanze. A questo punto ho alcune domande e
spero che qualcuno m’illumini!
Chi dice il vero (tra il tool e il misuratore)?
Non so se nel tuo caso sia plausibile, ma esiste una differenza anche
significativa tra misure effettuate su distanza cartesiana, su sfera o
su sferoide e sul sistema di riferimento che si adotta per
riproiettare i dati nell’effettuare i calcoli di distanza.
Ad es su un mio dataset tra Roma e Napoli, usando le funzioni
ST_Distance, ST_DistanceSphere e ST_DistanceSpheroid di PostGIS, ho
rispettivamente una distanza di:
ST_Distance: 191,761 km (riproiettando a UTM 32N)
ST_Distance: 255,388 km (riproiettando a mercator, come fanno tutti i web
gis, valore altamente impreciso!)
ST_DistanceSphere: 191,296 km
ST_DistanceSpheroid: 191,513 km (usando uno spheroid WGS 84)
notare la differenza della riproiezione a mercator!
ciao
Un saluto a tutti e grazie per i vari contributi,
provo a fare un riassunto della situazione:
Ho tutte feature singlepart EPGS:3857, progetto impostato sullo stesso CRS e
ho disattivato la riproiezione al volo. In questo modo i valori di fTools e
del misuratore coincidono e sembrano plausibili.
Ma poi ho fatto un'altra prova: ho disegnato le linee del campo sportivo (le
due linee di fondo, la linea di centrocampo e le due linee laterali)
sperando che siano le classiche 105x60, ho lanciato di nuovo fTools, invece
di 390m mi dà 557m.
come scritto prima, distanza Roma/Napoli:
* 191,761 km (riproiettando da EPSG:4326 a UTM 32N, EPSG:32632)
* 255,388 km (riproiettando da EPSG:4326 a EPSG:3857, come fanno tutti
i web gis, valore altamente impreciso visto che tale proiezione non
conserva le distanze!)
pertanto, per ottenere valori plausibili, converti i tuoi dati da
EPSG:3857 ad un sistema locale (ad es UTM 32 o 33 Nord per l'Italia) e
ripeti le misure, vedrai che i conti tornano.
Il giorno 02 ottobre 2013 10:48, Paolo Corti <pcorti@gmail.com> ha scritto:
2013/10/2 Daniele Bonaposta <daniele.bonaposta@gmail.com>:
> Un saluto a tutti e grazie per i vari contributi,
> provo a fare un riassunto della situazione:
>
> Ho tutte feature singlepart EPGS:3857, progetto impostato sullo stesso
CRS e
> ho disattivato la riproiezione al volo. In questo modo i valori di
fTools e
> del misuratore coincidono e sembrano plausibili.
> Ma poi ho fatto un'altra prova: ho disegnato le linee del campo sportivo
(le
> due linee di fondo, la linea di centrocampo e le due linee laterali)
> sperando che siano le classiche 105x60, ho lanciato di nuovo fTools,
invece
> di 390m mi dà 557m.
>
come scritto prima, distanza Roma/Napoli:
* 191,761 km (riproiettando da EPSG:4326 a UTM 32N, EPSG:32632)
* 255,388 km (riproiettando da EPSG:4326 a EPSG:3857, come fanno tutti
i web gis, valore altamente impreciso visto che tale proiezione non
conserva le distanze!)
pertanto, per ottenere valori plausibili, converti i tuoi dati da
EPSG:3857 ad un sistema locale (ad es UTM 32 o 33 Nord per l'Italia) e
ripeti le misure, vedrai che i conti tornano.
Una domanda un pelo OT, ma non troppo:
avendo un intero DB geografico che lavora in epsg3004 (gaussboaga EST) e volendolo condividere con persone che lavorano invece con Gauss Boaga Ovest, mi suggerivano di trasformare tutto in EPSG4326…ora, siccome si parla di archeologia e quindi di disegni di “coccetti per capirsi”, muri, pietre, buchette, quali effetti nefasti si avrebbe portando tutto in WGS84? E’ possibile mantenere oggetti con sistemi di riferimento locali diversi in un unico DB Geografico? Ho detto una cavolata?
Ciao
Luca
Un saluto a tutti e grazie per i vari contributi,
provo a fare un riassunto della situazione:
Ho tutte feature singlepart EPGS:3857, progetto impostato sullo stesso CRS e
ho disattivato la riproiezione al volo. In questo modo i valori di fTools e
del misuratore coincidono e sembrano plausibili.
Ma poi ho fatto un’altra prova: ho disegnato le linee del campo sportivo (le
due linee di fondo, la linea di centrocampo e le due linee laterali)
sperando che siano le classiche 105x60, ho lanciato di nuovo fTools, invece
di 390m mi dà 557m.
come scritto prima, distanza Roma/Napoli:
191,761 km (riproiettando da EPSG:4326 a UTM 32N, EPSG:32632)
255,388 km (riproiettando da EPSG:4326 a EPSG:3857, come fanno tutti
i web gis, valore altamente impreciso visto che tale proiezione non
conserva le distanze!)
pertanto, per ottenere valori plausibili, converti i tuoi dati da
EPSG:3857 ad un sistema locale (ad es UTM 32 o 33 Nord per l’Italia) e
ripeti le misure, vedrai che i conti tornano.
Ho riproiettato a EPSG:23032, i conti tornano!
Grazie
On Wed, Oct 02, 2013 at 12:18:40PM +0200, Luca Mandolesi wrote:
Una domanda un pelo OT, ma non troppo:
avendo un intero DB geografico che lavora in epsg3004 (gaussboaga EST) e
volendolo condividere con persone che lavorano invece con Gauss Boaga
Ovest, mi suggerivano di trasformare tutto in EPSG4326....ora, siccome si
parla di archeologia e quindi di disegni di "coccetti per capirsi", muri,
pietre, buchette, quali effetti nefasti si avrebbe portando tutto in
WGS84? E' possibile mantenere oggetti con sistemi di riferimento locali
diversi in un unico DB Geografico? Ho detto una cavolata?
E' possibile mantenere oggetti con sistemi di riferimento locali diversi
in un unico DB Geografico (nessuna cavolata).
Misurare "coccetti" in gradi/minuti/secondi e' altamente sconsigliato
Puoi trasformare da Gauss Boaga est a ovest, all'occorrenza.
Presumo te l'abbiano detto per un motivo molto semplice: il rilievo di
oggetti archeologici via GPS sarebbe immediato, senza bisogno di alcuna
conversione fra datum.
Il problema è la precisione dei ricevitori, che senza correzione
differenziale è nell'ordine dei 10 metri, quindi insufficiente per
l'archeologia.
Siccome un Gps con accuratezza centimetrale costa migliaia di euri, temo vi
convenga restare in un CRS proiettato....
Diciamo che il tutto partiva da un discorso INSPIRE (di cui sono totalmente ignorante in materia), che a quanto mi dicevano suggerisce di usare solo WGS84. Ma qui mi fermo.
Presumo te l’abbiano detto per un motivo molto semplice: il rilievo di
oggetti archeologici via GPS sarebbe immediato, senza bisogno di alcuna
conversione fra datum.
Il problema è la precisione dei ricevitori, che senza correzione
differenziale è nell’ordine dei 10 metri, quindi insufficiente per
l’archeologia.
Siccome un Gps con accuratezza centimetrale costa migliaia di euri, temo vi
convenga restare in un CRS proiettato…
E'
possibile mantenere oggetti con sistemi di riferimento locali diversi in un
unico DB Geografico? Ho detto una cavolata?
Se usi PostGIS (ma penso anche Spatialite lo consenta), puoi creare n
colonne geometriche per layer, una per ciascun sistema di riferimento.
Ovviamente lo spazio di storage aumenta sensibilmente e devi fare in
modo di mantenere in sincronia le n colonne se il tuo database viene
editato, magari con un trigger o con una procedura schedulata.
Il giorno Wed, 2 Oct 2013 05:02:40 -0700 (PDT)
Novarese <sieradz@gmail.com> ha scritto:
ciao Novarese:-)
premesso che non conosco i gps e solo ora sto affrontando le
conversioni/trasformazioni di coordinate, questa parte del tuo
discorso, sempre che abbia capito bene :-), non mi torna:
......
Il problema è la precisione dei ricevitori, che senza correzione
differenziale è nell'ordine dei 10 metri, quindi insufficiente per
l'archeologia.
Siccome un Gps con accuratezza centimetrale costa migliaia di euri,
temo vi convenga restare in un CRS proiettato....
la precisione non dipende dal sistema di riferimento, ma è un parametro
relativo: il mio WildT2 ha un errore angolare di tot, il mio Distomat
un errore lineare di tot, il gps (che non ho) avrà un errore di tot;
qualunque operazione/conversione/trasformazione andrò a fare, quegli
errori si ripercuoteranno sui risultati;
sarebbe troppo bello avere un sistema che ci mettesse al riparo da
ciò
spero di non aver equivocato il tuo punto di vista nel qual caso ti
chiedo scusa e la pazienza di chiarirmelo meglio
In effetti intendevo un'altra cosa, ma probabilmente non mi sono spiegato
bene io.
Allora, poiche' la localizzazione di oggetti archeologici richiede una
precisione altissima (del tipo: l'estradosso di questo muro maestro parte
dal punto x1,y1 e termina a 8.49 metri di azimut 37°), se si vuole un
rilievo georeferenziato forse il modo migliore e' un Gps submetrico, giusto?
Ora, dato che un attrezzo simile costa caro, non so quanti centri
archeologici possano permettersene uno, ergo rinunciano ad una tale
comodita', ergo non rilevano in coordinate lat/long, ergo restano nel
tradizionale Gauss-Boaga proiettato...
