Piszę skrypt w języku Python, który odczytuje wiele plików XML zawierających współrzędne xiy i łączy je wszystkie w jeden plik csv. Szerokość i długość geograficzna są polami wymaganymi w pliku csv, ale mam trudności z konwersją współrzędnych x, y w Ohio North State Plane usFt na WGS84.
>>> p = Proj(r'+proj=lcc +lat_1=41.7 +lat_2=40.43333333333333 +lat_0=39.66666666666666 +lon_0=-82.5 +x_0=600000 +y_0=0 +ellps=GRS80 +datum=NAD83 +units=us-ft +no_defs') #Nad83 State Plane Ohio North US Feet Proj object using parameters
>>> p(739400.91,2339327.3,inverse=True)
(-80.138057868777224, 60.278230707978487)
>>> p1 = Proj(init="epsg:3734") #Nad83 State Plane Ohio North US Feet Proj object using EPSG code
>>> p1(739400.91,2339327.3,inverse=True)
(-80.138057868777224, 60.278230707978487)
Obie powyższe metody zwracają ten sam wynik, jednak ten długi czas jest gdzieś w Zatoce Hudsona. Kiedy wykreślam współrzędne w ArcMap, prawidłowa długość to: -81.142311,41.688205.
* Zwróć uwagę, że wszystkie długości są dostarczane długo, ponieważ jest to kolejność stosowana przez Proj
Czy ktoś wie, dlaczego otrzymuję nieprawidłowe współrzędne z Proj.4 i pyproj?
źródło
p1 = Proj( init="epsg:3734", preserve_units=True )
W rzeczywistości próbowałem zrobić to samo, z wyjątkiem siatki stanu południowego OH i natknąłem się na twoje pytanie. Miałem złe wyniki z 3735, teraz otrzymuję prawidłowe wyniki z 3729. Spodziewam się, że jeśli zmienisz z 3734 na 3728, otrzymasz poprawne wyniki.
EPSG: 3728: NAD83 (NSRS2007) / Ohio North (ftUS) EPSG: 3729: NAD83 (NSRS2007) / Ohio South (ftUS) EPSG: 3734: NAD83 / Ohio North (ftUS) EPSG: 3735: NAD83 / Ohio South (ftUS)
Użyłem twojego zapewnionego lat, długi i jestem mniej niż o jedną stopę.
p2 = pyproj.Proj (init = "epsg: 3728", preserve_units = True)
p2 (-81.142311,41.688205)
(2339326.6558868014, 739401.4226131936)
vs 2339327,3, 739400,91
źródło