Hot answers tagged

31

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


21

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


14

The proj4string is a valid PROJ4 crs string. see How can I get the proj4 string or EPSG code from a shapefile .prj file? and Shapefile PRJ to PostGIS SRID lookup table? in short: You can use gdalinfo as in the first reference or the GDAL Python bindings as in the second reference. Or go to Prj2EPSG (a simple service for converting well-known text ...


13

Your attempt is designed to fail. If you look at the image, you see the data arranged as a circle, with black triangles in the corners of the square, where the satellite view goes right into orbit. In your test data, you see only NODATA -32768 for those parts of the image. The extent is between +/-75 and +/- 78, but these values are only reached in the ...


12

In https://gis.stackexchange.com/questions/158457/gdal2tiles-how-to-make-filenames-of-tiles-to-represent-xyz-coordinates, somebody mentions doing: sudo ln -s /usr/lib/libproj.so.0 /usr/lib/libproj.so Which absolutely fixed the same error (ERROR 6: Unable to load PROJ.4 library (libproj.so)) for me. On the x86_64 architecture you may need to use this ...


12

The EPSG:32719 is a UTM Zone 19 south setup with: $ grep -B1 '<32719>' /usr/share/proj/epsg # WGS 84 / UTM zone 19S <32719> +proj=utm +zone=19 +south +datum=WGS84 +units=m +no_defs <> which is a shortcut defined in /usr/share/proj/epsg. For the background you can refer to the PROJ.4 description. If you use the full parameter set for ...


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

Here is a very handy website for retrieving the EPSG code for a given projection. In your case the projection is "EPSG:27700". If you have projections defined for the shapefile you can assign the projection when you create the SpatialPointsDataFrame and then use the projection definition from your imported shapefile. Using "readOGR" from the rgdal package ...


10

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.


9

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)


9

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


9

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


9

This projection has been added to the 5.2.0. version of PROJ.4. If you go in QGIS to Help>>About, you'll see that it uses an earlier version of PROJ.4 If you want this projection now, you'll have to wait for the newer version of QGIS (Which would use this updated Proj.4 version), or you can compile QGIS yourself.


9

Yes, it's case sensitive. Each +parameter=value pair are normally case sensitive. For example with the parameter, there are two separate ellipsoid radius parameters R_A and R_a, which have different meanings. And an example where the value is case sensitive is on case-sensitive systems (e.g. Linux), where the lowercased +nadgrids=beta2007.gsb fails to find ...


8

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 84",DATUM["WGS_1984",SPHEROID["WGS84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",...


8

After several wrong ways, including multiple reinstall of libproj0 package and even installing QGIS from sources different from the Ubuntu Software Center default (I think it's from the official QGIS repository - http://qgis.org/debian trusty main), I understood how to apply advice by @EvilGenius: ldd ogrinfo didn't show libproj no matter how many times I ...


7

You can now do this directly with the ggalt package: library(ggplot2) library(ggalt) library(ggthemes) wrld <- map_data("world") gg <- ggplot() gg <- gg + geom_map(data=wrld, map=wrld, aes(x=long, y=lat, map_id=region), color="#2b2b2b", size=0.15, fill=NA) gg <- gg + coord_proj("+proj=robin +lon_0=0 +x_0=...


7

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


7

Try: sudo apt-get install libproj-dev It solved the same error for me when using gdal_translate for extracting bands from an hdf image.


7

Technically, I think you have two questions. The first is just what's the WKT for this PROJ.4 string. The second is about how a CRS WKT is structured. An answer to the second question is probably too long for Stackexchange, but I've put some pointers below. In answer to the first (should be single line, formatted into multiple lines for readability), I'm ...


7

The units are within the projection of the view. From a map object, you can get it using: var units = map.getView().getProjection().getUnits(); See also the API documentation of the ol.proj.Projection#getUnits method. Here's also an example method to get the scale from a given resolution: var INCHES_PER_UNIT = { 'm': 39.37, 'dd': 4374754 }; var ...


7

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


7

Your data seems to be in Haiti, using the North American Datum of 1927. QGIS and GDAL use the datum grid shift files for NAD27 for USA and Canada, but unfortunately your data is just outside the conus grid file. hence all your reprojections get a null shift, which is definitely wrong. Clifford J. Mugnier published a Grids & Datums article on Haiti in ...


7

In Twitter Tom Patterson posted this tweet and it works: The latest #QGIS 3.4.0 supports #EqualEarthProjection in two steps:(1) In Settings -> Custom Projections… create a custom definition with “+proj=eqearth +datum=WGS84 +wktext”(2) Select the definition in Project -> Properties… -> CRS -> under “User Defined Coordinate System” pic.twitter.com/...


7

Use the rgdal package and showP4: Your string: > ps [1] "COMPD_CS[\"Projected\", PROJCS[\"UTM_10N\", GEOGCS [ \"WGS84\", DATUM [ \"WGS84\", SPHEROID [\"WGS 84\", 6378137.000, 298.257223563 ], TOWGS84 [ 0.000, 0.000, 0.000, 0.0000000000, 0.0000000000, 0.0000000000, 0.0000000000 ] ], PRIMEM [ \"Greenwich\", 0.000000 ], UNIT [ \"metres\", 1.00000000] ], ...


7

Reprojecting rasters is usually a bad thing to do. It involves a non-reversible transformation from one grid system to another grid system that can have a non-linear relationship to the first. Hence the value in a cell of the new system can end up being some average of whichever grid cells in the source raster it overlapped. If you have a raster and points ...


6

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


6

Basically you need to cut the raster into two parts and piece them back together with a new offset/scale. There's an example here of how to do that from [-180,180] to [0,360] with gdal_translate and the VRT driver: http://trac.osgeo.org/gdal/wiki/UserDocs/RasterProcTutorial Scan down to the "5 min tutorial" and the details are under "Virtual Files". It ...


6

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


6

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


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