Hot answers tagged

50

While shapely doesn't natively understand coordinate systems, shapely.ops.transform() can do that along with pyproj. If pyproj.Proj can understand your both of your coordinate systems, then it can be made into a function that shapely can transform with. From the shapely docs: from functools import partial import pyproj from shapely.ops import transform ...


17

If the crs of the GeoDataFrame is known (EPSG:4326 unit=degree, here), you don't need Shapely, nor pyproj in your script because GeoPandas uses them). import geopandas as gpd test = gpd.read_file("test_wgs84.shp") print test.crs test.head(2) Now copy your GeoDataFrame and change the projection to a Cartesian system (EPSG:3857, unit= m as in the answer of ...


11

While not a Shapely solution, using GeoPandas allows for relatively straightforward projection. For example, if we want to convert a shapefile to ESPG 4326: import geopandas as gpd HabModelEnviro = gpd.GeoDataFrame.from_file('data/HabModelEnviro.shp').replace({-999: None}) HabModelEnviroWGS84 = HabModelEnviro.to_crs({'proj':'longlat', 'ellps':'WGS84', '...


10

At the first question, 'epsg:32054' code has feet units. For this reason, it is necessary to use 'preserve_units=True' as parameter in inProj = Proj(init='epsg:32054') line. Now, next code works well: from pyproj import Proj, transform # wisconsing EPSG:32054 # epsg:4326 is for the entire world, wgs 84...not obvious inProj = Proj(init='epsg:32054', ...


10

Both coordinates are the same. As you are in the Southern Hemisphere a False Northing (of +10000000m) is usually applied to eliminate the negatives. The utm package applies the false Northing by itself. For Proj you need to specify it: >>> p = Proj(proj='utm', ellps='WGS84', zone='34H', south=True) >>> p(lon,lat) >>> (261762....


9

Simply use (Converting elevations into correct units with pyproj?, Proj4 String for NAD83(2011) / Louisiana South (ftUS), ...) preserve_units=True (as you say, pyproj assumes that your coordinates are in meters, therefore) for northing, easting, up in targets: print "Converting", easting, northing # Transform using pyproj (gives wrong answer) ...


7

For that, you must know the real Python world and the modern way to install modules. 1) The pyproj module needs the compilation of many C libraries and Windows has no compiler by default as in Linux or Mac OS X so you can't install the module with setuptools , easy_install or pip, the traditional way to install modules or unzipping the folder in C:\...


7

You can calculate the UTM zone of each town center from the longitude, starting at zone 1 from -180°E to -174°E. zone=ROUND((183+longitude)/6;0) should calculate that in one step. The EPSG code is 32600+zone for positive latitudes and 32700+zone for negatives. Together in one formula: EPSG=32700-ROUND((45+latitude)/90;0)*100+ROUND((183+longitude)/6;0) ...


7

Probably because in lon, lat, alt = 49.74761271, -113.2179781, 0 a lat of -113.2179781 is outside the valid bounds of -90 to 90.


7

If you examine the answer of afalciano in Converting projected coordinates to lat/lon using Python? 1) you define the two projections # original projection p = pyproj.Proj("+proj=stere +lat_0=90 +lat_ts=60 +lon_0=-105 +k=90 +x_0=0 +y_0=0 +a=6371200 +b=6371200 +units=m +no_defs") # resulting projection, WGS84, long, lat outProj =pyproj.Proj(init='epsg:4326')...


6

It looks like you've done everything correctly. You can evaluate the errors from each method by performing the inverse calculations to find the distance given the origin and destination coordinates, then evaluate the residuals of distances. This is a round-trip exercise. # For Vincenty's method: geopy_inv_dist = geopy.distance.vincenty(origin, destination)....


6

from pyproj import Proj, transform print(transform(Proj(init='epsg:4326'), Proj(init='epsg:3857'), -0.1285907, 51.50809)) # longitude first, latitude second. # output (meters east of 0, meters north of 0): (-14314.651244750548, 6711665.883938471) The "trick" is to use these shortcuts for Web Mercator (EPSG 3857) and WGS 84 longitude and latitude (EPSG 4326)...


5

Many projected coordinate systems use a false Easting and/or a false Northing to avoid negative coordinates and/or to reduce potential ambiguities with other CRS of the same region. In the case of UTM 18N, the origin of the projection, in lat long, is (0°, -75°), but the false easting is 500 000 m meaning that the XY coordinate system has been shifted. ...


5

List pj_list gives you at least projections the proj command understands. The EPSG context in the proj.4 biotop is a simple file based "DATABASE" that connects ONLY EPSG number entries (KEYS) with initialization params of the tool proj. You will find the data in the file /usr/share/proj/epsg if you use proj.4 and one of it's bindings in LINUX. Each ...


5

You can use the osr module (part of the standard GDAL install, so it should come with your Python bindings) and do something like this: import osr import gdal inDS = gdal.open(r'c:\somedirectory\myRaster.tif') inSRS_wkt = inDS.GetProjection() # gives SRS in WKT inSRS_converter = osr.SpatialReference() # makes an empty spatial ref object inSRS_converter....


5

You make a mistake with the pyproj parameters from pyproj import Proj, transform inProj = Proj("+init=EPSG:3857")) outProj = Proj("+init=EPSG:4326") x1,y1 = (-20037507.0672, 20037509.6184) x2,y2 = (-1467048.29156, 8625918.8737) # with the x,y coordinates of pointx print transform(inProj,outProj,x1,y1) (-179.99998854118687, 85.08398750388278) # with the ...


5

The result you are seeing is in fact correct. Looking at your code you create your hexagons in UTM32N but Leaflet displays them using EPSG:3857 (aka Web Mercator) which "stretches" as you go north (or south) from the equator. So your hexagons cover a wider distance (east-west) as you move north making them look stretched. If you are intending to do some ...


4

As AndreJ assumed, I'm believe you meant EPSG::32632, WGS 1984 / UTM Zone 32 North. It's a projected coordinate reference system and its unit of measure is the meter, not decimal degrees. If your lat/lon coordinates fall within that zone, the values should range between: Easting: 200 km to 800 km Northing: 0 km to 10000 km


4

Projection of this kind of files is sinusoidal. For this one: ftp://ladsweb.nascom.nasa.gov/allData/6/MOD13Q1/2016/129/MOD13Q1.A2016129.h07v06.006.2016147112419.hdf the next code can access to coordinates for 256 values for subDatasets[0][0] (NDVI values). from osgeo import gdal import struct nameraster = "/home/zeito/Desktop/MOD13Q1.A2016129.h07v06....


4

Look at Proj4 String for NAD83(2011) / Louisiana South (ftUS) preserve_units=True fix the problem (pyproj silently changes '+units=' parameter) import pyproj proj2 = pyproj.Proj(init='epsg:32051',preserve_units=True) proj1 = pyproj.Proj(init='epsg:4326') print pyproj.transform(proj1, proj2, *point_4326) (1933041.523059067, 258416.59493967678, 2191....


4

I believe yes. The following ought to work: gdf['geometry'].to_crs({'init': 'epsg:3395'})\ .map(lambda p: p.area / 10**6) This converts the geometry to an equal-area projection, fetches the shapely area (returned in m^2), and maps that to a km^2 (this last step is optional).


4

The proj4 library has an error identifying the difference between Israel TM Grid 2039 and IG 05/12 6991. Survey if Israel made a horrendous error and updated 2039 to include the new 7 parameter Coordinate Frame transformation, instead of the previous 3 parameter Molodansky, and left 6991 without the new and correct transformation. I've created the correct ...


4

As of 30 March 2017, no, there are no coordinate reference system, nor transformations for BD-09 or GCJ-02 in the EPSG Registry. As far as I'm aware as a member of the subcommittee that maintains the registry, no request has been made to add either one. A big issue with a request is getting reliable information as part of the request even of the geographic ...


4

The formulae you have used are for the spherical case. However, your proj4 string indicates that you are using an ellipsoid (+ellps=krass). In order to get the proper results on the ellipsoid, you will have to implement the ellipsoidal formulae. These formulae can be found in this working manual from USGS at page 101. The parameters for different ...


4

This is a great question and I will do my best to answer. To begin, the init style syntax is deprecated (https://pyproj4.github.io/pyproj/stable/gotchas.html#init-auth-auth-code-should-be-replaced-with-auth-auth-code). So, instead of CRS(init="epsg:4544"), you should use CRS("epsg:4544"). I discovered that sometimes when intialising a pyproj Proj ...


3

Here's some example code using pyproj. Given a point in lat lon, it calculates new lat lon points given a distance in meters and an azimuth. The azimuth comes from the aspect ratio of the rectangle. from math import sqrt,atan,pi import pyproj geod = pyproj.Geod(ellps='WGS84') width = 10000. # m height = 20000. # m rect_diag = sqrt( width**2 + height**2 ) ...


3

The geopy pull request fixes your issue with geopy. You will need to install the python package geographiclib first with pip install geographiclib


3

Also check out Lars Butler's https://github.com/larsbutler/geomet, a pure Python WKT/WKB <-> GeoJSON converter.


3

Sure. In that case, you need to transform each point separately. First parse WKT and extract point coordinates, then loop over coordinates and perform transformation like: import pyproj srcProj = pyproj.Proj(init='epsg:%i' % epsg_in, preserve_units=True) dstProj = pyproj.Proj(init='epsg:%i' % epsg_out, preserve_units=True) x_out,y_out = pyproj.transform(...


3

Pyproj was automatically converting the feet to meters when establishing a Proj object. The issue was resolved when I added: oriproj = Proj(shape.crs, preserve_units=True)


Only top voted, non community-wiki answers of a minimum length are eligible