Hot answers tagged

54

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 ...


18

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 ...


13

If you're using pyproj2, it's much easier to use a Transformer. Here's an example: import pyproj from shapely.ops import transform project = pyproj.Transformer.from_proj( pyproj.Proj(init='epsg:4326'), # source coordinate system pyproj.Proj(init='epsg:26913')) # destination coordinate system # g1 is a shapley Polygon g2 = transform(project....


13

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

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) ...


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) ...


8

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:\...


8

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)...


8

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')...


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

The +init=epsg:xxxx syntax (or in form of a {'init': 'epsg:xxx'}) is being deprecated in PROJ / pyproj (see here. You are indeed not using it directly, but, the previous releases of GeoPandas (<= 0.6) were still generating this format under the hood (e.g. when reading files, as you can see from the output of df.crs). That is the reason you see this ...


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

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 ...


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

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


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

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

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

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 ...


5

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).


5

The +init= syntax is deprecated. So all you need is the ESRI:102001 part. See: https://pyproj4.github.io/pyproj/stable/gotchas.html#init-auth-auth-code-should-be-replaced-with-auth-auth-code inputGDF.crs = 'esri:102001'


5

You should try to preserve the WKT form if possible. See: https://proj.org/faq.html#what-is-the-best-format-for-describing-coordinate-reference-systems It all depends on the version of geopandas. When version 0.7.0 comes out, you can do: boxes = geopandas.GeoDataFrame() with rasterio.open(raster_path) as dataset: boxes.crs = dataset.crs boxes.to_file(...


5

'<authority>:<code>' in the error means that you need just to use crs='EPSG:4326' instead of crs={'epsg:4326'}.


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

This should do the trick. I haven't been able to install the pyproj module, but at the point marked #do transformation. I tested it by doing simple arithmetic. I put in the function based on your code. Basic structure is: Load data from file. Traverse json string - essentially nested dictionaries and lists Iterate through the coordinates. The coordinate ...


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 ...


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