Hot answers tagged

17

PyProj assumes that your coordinates are in meters. I'd guess something relating to feet/meters is the cause of the issue. Calling a Proj class instance with the arguments lon, lat will convert lon/lat (in degrees) to x/y native map projection coordinates (in meters) If the optional keyword 'preserve_units' is True, the units in map ...


15

The shapefile should have a .prj file which defines the projection. You can use it together with one of the following 3 options to get either the proj4 string, WKT definition or EPSG code. To get proj4 definition: If you have gdal installed on your system, you can use the gdalsrsinfo command line application to get the proj4 definition as the OGC WKT ...


11

It might be tricky to handle Robinson from within ggplot2. AFAIK ggplot2 coord_map solution you explored will use projection information as defined in mapproject package. There are few available there but unfortunately Robinson is not one of them and I'm not sure if you can add your own. Also - the world data you are using (from ggmap package I presume) ...


10

You could explicitly set the output coordinate range using the target extent option to gdalwarp (ie. "-te -180 -90 180 90") but you can also use the CENTER_LONG configuration option to force rewrapping around a new central longitude. Something like this: gdalwarp -t_srs WGS84 ~/0_360.tif 180.tif -wo SOURCE_EXTRA=1000 \ --config CENTER_LONG 0 ...


9

The OGR Spatial Reference part of GDAL should do the trick. capooti provided an excellent answer to another question which demonstrates how to peform the translation from a shapefile to WKT. You may also want to check out the class reference. The reverse is simply: from osgeo import osr srs = osr.SpatialReference() wkt_text = ...


8

I get the same results as @geographika when I run gdaltransform and the proj.4 tool cs2cs: $ gdaltransform -s_srs EPSG:3734 -t_srs EPSG:4326 739400.9 2339327.3 -87.3195485720169 45.9860670658218 0 cs2cs +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 ...


8

First, Proj4 uses what EPSG calls the "Position Vector" version of the 7 parameter method. It's possible that GeoTrans and Leica GeoOffice use the other version which EPSG called "Coordinate Frame". Both methods are equivalent, but the rotation matrices are different and the signs of the angular parameters have to be changed. Second, thank you for ...


8

The answer is Pyproj. Transforms lists of coordinates in a single call, and since it's a C extension module that uses PROJ.4, the same results as cs2cs but at C speed.


7

Your input coordinates are in the wrong order. Pyproj expects long, lat. >>> import pyproj >>> p = pyproj.Proj(init='epsg:32633') >>> p(*p(15.6, 58.4), inverse=True) (15.6, 58.399999999999991)


7

As was stated in the comments, QGIS doesn't do interrupted projections. You could use the Generic Mapping Tools (GMT) to reproject your vector files strip by strip and stitch them together. Note that for making a globe, you probably want the transverse Mercator projection (that's also the one used in the boehmwanderkarten.de code): This image was created ...


6

The official OGC “Well-known Text Representation of Spatial Reference Systems” for EPSG 4326 (http://spatialreference.org/ref/epsg/4326/ogcwkt/) is (your second projection): GEOGCS["WGS ...


6

It's EPSG:6372, a projection for Mexico, defined by the Instituto Nacional de Estadística y Geografía (INEGI).


5

I've run your coordinates through gdaltransform: $ gdaltransform -s_srs EPSG:32017 -t_srs EPSG:4326 759232.003438, 1149854.52147 -77.6116223688997 43.1517747887723 0 And it appears to come up with the right answer. This means that proj4 (which GDAL and PyProj are based on) is doing the right thing. Sometimes these sorts of errors can be caused by ...


5

Your source coordinate system is most likely not defined in the CVS file that GDAL searches for proj4 strings. It looks like you might be able to pass the source EPSG as 3031 (from spatialreference.org) Note that it looks like your input is in a local projection. Is this clipped from a larger raster? To explicitly define the source you could just provide ...


5

For such problems, I try to visualize the points in QGIS to see where they are placed. From your parameters, I created a custom CRS with the definition: +proj=sterea +lat_0=54.4353877827032 +lon_0=18.4514121640352 +k=0.999790760649094 +x_0=41614.2107651061 +y_0=17150.1692507701 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs and created points in ...


5

PROJ.4 strings always want the false easting (x_0) and false northing (y_0) in meters, no matter what the coordinate reference system units are. Change +x_0 to 1000000.0 and you should get the results you want.


5

As as there is no support EPSG:6479 (NAD83(2011) / Louisiana South (ftUS)) in PROJ4 (look at the comment of mkennedy) I will illustrate the problem with EPSG:3452, NAD83 / Louisiana South (ftUS) because the problem is the same, the units of the projection. Solution with Pyproj import pyproj southla = pyproj.Proj('+proj=lcc +lat_1=30.7 +lat_2=29.3 ...


5

No. One uses GRS 80 Ellipsod and the other uses WGS 1984 Ellipsoid. Semi-major axis Inverse of flattening WGS84 6378137 298.257223563 GRS80 6378137 298.257222101 There is small difference between the flattening of the two ellipsoids but before fretting too much about it, let's calculate how different are the minor semi-axis of the two ellipsoids: ...


4

Looking here, you can use the +pm parameter to specify your own prime meridian relative to Greenwich, so using this command: $ cs2cs +proj=latlong +datum=WGS84 +to +proj=latlong +datum=WGS84 +pm=180dW I get this: 0.0 0.0 180dE 0dN 0.000 1 0 181dE 0dN 0.000 179 0 359dE 0dN 0.000 -179 0 1dE 0dN 0.000 Which seems to be what you want. I'm not ...


4

I was actually trying to do the same thing except with the OH south state plane grid and I came across your question. I was getting wrong results with 3735, now I get correct results with 3729. I expect if you change from 3734 to 3728, you will get the correct results. EPSG:3728: NAD83(NSRS2007) / Ohio North (ftUS) EPSG:3729: NAD83(NSRS2007) / Ohio South ...


4

Well, screw the ordnance survey of Mecklenburg-Vorpommern (and Brandenburg for that matter). They decided to go with their own custom CRS which add a leading 3 or 33 to the easting value (must remind them of their beloved Gauß-Krüger coordinates I suppose). I know that at least in Brandenburg they were offically forced to use the official UTM variants in the ...


4

If you read carefully the page you mentioned first, you see that EPSG:29902 is the correct CRS. The shapefiles do not have a .prj file. For reprojecting, you might create one on your own, or load the data in QGIS, set the CRS to EPSG:29902, and Save As... QGIS creates the following prj file: ...


4

After further investigation, I've managed to solve the problem. What is causing the problem is that Proj4js will dynamically load any parts it needs rather than immediately loading all of it's scripts. Internet Explorer has most trouble with this, but also Firefox and Chrome show the symptom. IE managed to not be able to use any transformations, even after ...


4

You seem to be looking to conduct an affine transformation between your local coordinate system and a georeferenced coordinate system. Affine transforms underly all coordinate systems and can be represented by the matrix equation below. |x_1 y_1 1| |a d| |x'_1 y'_1| |x_2 y_2 1| |b e| = |x'_2 y'_2| |x_3 y_3 1| |c f| |x'_3 y'_3| input transform. ...


4

Please note that Proj.4 and proj4js are not identical. If you download the latest version of proj4js, you find the defined projections in the lib/projections folder. Regarding EPSG codes, proj4js only has a few definitions, look into lib/global.js or see http://proj4js.org/ But it is possible to build all other definitions yourself if you take the proj4 ...


4

Your Gauss-Krueger projection uses +datum=potsdam. Up to 2012, this was hard coded in proj4 to a very unprecise value using a 3-parameter-transformation. You find more exact values for 7-parameter transformations in this topic: http://forum.openstreetmap.org/viewtopic.php?id=12723 There is an even better ntv2-grid transformation available here (take the ...


4

Behrman is special case of cylindrical equal area. There is some information about this as well as a warning about an issue in some old Proj4 versions in this thread http://groups.google.com/forum/#!topic/oracle_ugent/2WUt9HmcrHU. Proj4 string to use is +proj=cea +lon_0=0 +lat_ts=30 +x_0=0 +y_0=0 +datum=WGS84 +ellps=WGS84 +units=m +no_defs


4

The proj.4 definitions that are implemented in GDAL (which works in the background of QGIS) can be found here: https://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogr_srs_proj4.cpp There is no code for kav7, hence the projection can not be supported. You may ask on the GDAL developer mailing list for reasons. Maybe it is just too exotic so that noone ...


4

Using an azimuthal projection makes it easy to rotate a raster (or any geographic layer, for that matter). Just pretend the data are in a polar azimuthal projection and change its central longitude by the negative of the angle. Here, for example, is a bare-bones R function illustrating the procedure. Its arguments are a raster object x, an angle of ...


3

I found that manually conforming my WKT to the BNF described here eliminates the errors. Content repeated below: <coordinate system> = <projected cs> | <geographic cs> | <geocentric cs> <projected cs> = PROJCS["<name>", <geographic cs>, <projection>, {<parameter>,}* <linear unit>] ...



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