2011-07-21 9 views
8

Ho provato quanto segue, input: dati lat/lon quindi calcolerò una casella attorno ad esso, diciamo 50 m, quindi +/- 50 m sul valore di est/nord.lat/lon to utm a lat/lon è estremamente imperfetto, come mai?

Ora riconvertirlo al lat/lon e con uno script:

http://robotics.ai.uiuc.edu/~hyoon24/LatLongUTMconversion.py ottengo un risultato che proprio non può essere, lon prima che è di circa 7, poi intorno 2.

zone, easting, northing = LLtoUTM(23, location.get_lat(), location.get_lon()) 

topUTM = northing + error 
bottomUTM = northing - error 
leftUTM = easting - error 
rightUTM = easting + error 
left, top = UTMtoLL(23, leftUTM, topUTM, zone) 

L'errore nel mio codice o potrebbe essere la sceneggiatura imperfetta?

Così ho cercato di usare pyproj, basta lat/lon a UTM di latitudine/longitudine per vedere cosa succede

>>> p = pyproj.Proj(proj='utm', zone=32, ellps='WGS84') 
>>> p 
<pyproj.Proj object at 0x7ff9b8487dd0> 
>>> x,y = p(47.9941214, 7.8509671) 
>>> print x,y 
5159550.36822 1114087.43925 
>>> print p(x,y,inverse=True) 
(47.971558538495991, 7.8546573140162605) 

E qui non è così estremamente lontani come con lo script dall'alto, ma sembra ancora abbastanza incorretto da non essere in grado di usarlo. Come mai? Cosa posso fare per ottenere risultati più precisi?

EDIT:

ho eseguito test() ed esso tutti i test passati.

in file epsg non esiste una cosa del genere. Il più vicino che ho trovato è stato questo:

<32632> +proj=utm +zone=32 +ellps=WGS84 +datum=WGS84 +units=m +no_defs <> 

no tmerc. Inoltre, cosa avrei bisogno per passare il towgs84 come parametri? Quelli sopra?

risposta

2

Il tuo problema con il pyProj suona proprio come quello descritto qui:

http://code.google.com/p/pyproj/issues/detail?id=3

che si risolve:

solved! in epsg file there must be

<2392> +proj=tmerc +lat_0=0 +lon_0=24 +k=1.000000 +x_0=2500000 +y_0=0 +ellps=intl +towgs84=-90.7,-106.1,-119.2,4.09,0.218,-1.05,1.37 +units=m +no_defs no_defs <>

note the towgs84 parameter!

Controllare il thread out se si desidera continuare a utilizzare pyproj.

Inoltre, la funzione test() del modulo funziona? Hai provato uno qualsiasi degli script inclusi nella directory test?

+0

Coloro che sperano che Ubuntu 13.04 Raring dovrebbe includere un PyProj up-to-date si troverebbero in errore. Installa dalla fonte! – Richard

23

ho creato una piccola biblioteca di conversione UTM per Python scorsa settimana e lo ha caricato per l'Indice Python Package: http://pypi.python.org/pypi/utm

ho paragonato a utilizzare pyproj ed è più veloce e più accurata. Dato vostri dati di esempio, questo è il risultato:

>>> import utm 

>>> u = utm.from_latlon(47.9941214, 7.8509671) 
>>> print u 
(414278, 5316285, 32, 'T') 

>>> print utm.to_latlon(*u) 
(47.994157948891505, 7.850963967574302) 

UPDATE: Richards answer seguente descrive la vera soluzione per questo problema.

+0

Grazie! Funziona semplicemente perfetto –

+0

Grazie per l'urlo, @TBieniek! – Richard

+0

Grazie mille per questa implementazione, assolutamente preziosa! – Blackbrook

17

L'errore è nel codice.

Prima di tutto, il problema PyProj elencato in una delle altre risposte è reale. Si dovrebbe controllare il file EPSG e assicurarsi che include la linea

<2392> +proj=tmerc +lat_0=0 +lon_0=24 +k=1.000000 +x_0=2500000 +y_0=0 +ellps=intl +towgs84=-90.7,-106.1,-119.2,4.09,0.218,-1.05,1.37 +units=m +no_defs no_defs <> 

Nota il parametro towgs84.

Il tuo problema con PyProj deriva dall'errato utilizzo del comando di proiezione.

Se prendiamo il 47.9941214N, il 7.8509671E e il convert to UTM otteniamo la Zona 32, l'Easting 414278, il Nording 5316286.

di eseguire le seguenti operazioni PyProj:

p = pyproj.Proj(proj='utm', zone=32, ellps='WGS84') 
>>> x,y = p(47.9941214, 7.8509671) 
>>> print x,y 
5159550.36822 1114087.43925 
>>> print p(x,y,inverse=True) 
(47.971558538495991, 7.8546573140162605) 

Ma, se consultiamo il PyProj documentation, vediamo quanto segue:

Calling un'istanza di classe Proj con gli argomenti lon, volontà lat convertire coordinate lon/lat (in gradi) a x/y native map (in metri).

Proviamo a eseguire nuovamente le operazioni PyProj della OP, ma cambiare l'ordine degli argomenti lat lon /:

p = pyproj.Proj(proj='utm', zone=32, ellps='WGS84') 
>>> x,y = p(7.8509671, 47.9941214) 
>>> print x,y 
414278.16731 5316285.59492 
>>> print p(x,y,inverse=True) 
(7.850967099999812, 47.994121399999784) 

L'operazione in sé inverte (più o meno) perfettamente!

Per rispondere alla prima parte della tua domanda, se si guarda in http://robotics.ai.uiuc.edu/~hyoon24/LatLongUTMconversion.py alla definizione di UTMtoLL, si trova il seguente:

UTMtoLL(ReferenceEllipsoid, northing, easting, zone) 

Eppure si utilizza UTMtoLL(23, leftUTM, topUTM, zone) dove leftUTM è un Easting e topUTM è un Northing .

Pertanto, nel caso del primo script e di PyProj, è stato utilizzato l'ordine errato degli argomenti.

È un buon promemoria per sempre controllare due volte (o triple) il tuo lavoro prima di suggerire che qualcun altro ha torto. Detto questo, la documentazione di Python è not the greatest e la documentazione di PyProj in questo caso è criptica al meglio. Una buona spiegazione basata sul web di questo comando e accompagnata da esempi del suo utilizzo avrebbe probabilmente prevenuto l'angoscia da parte vostra.

1

Non ho alcun problema con pyproj, provare il seguente codice

from pyproj import Proj 

Lat = 52.063098675 
Lon = -114.132980348 #Calgary 

ZoneNo = "11" #Manually input, or calcuated from Lat Lon 
myProj = Proj("+proj=utm +zone="+ZoneNo+",\ 
+north +ellps=WGS84 +datum=WGS84 +units=m +no_defs") #north for north hemisphere 
UTMx, UTMy = myProj(Lon, Lat) 

######################################## 

#UTM ==> Lat Lon: 
ZoneNo = "11" #Manually input or from other sources 
myProj = Proj("+proj=utm +zone="+\ 
ZoneNo+", +north +ellps=WGS84 +datum=WGS84 +units=m +no_defs") 
Lon2, Lat2 = myProj(UTMx, UTMy,inverse=True) 

print Lat2 
print Lon2 
Problemi correlati