Hot answers tagged

58

They are not the same. EPSG:4326 refers to WGS 84 whereas EPSG:900913 refers to WGS84 Web Mercator. EPSG:4326 treats the earth as an ellipsoid while EPSG:900913 treats it as a sphere. This affects calculations done based on treating the map as a flat plane which is why your features got plotted on the wrong places.


55

900913 = GOOGLE (spelled with numbers). There is no official EPSG code 900913, because for some time this reference system wasn't added into the EPSG list of spatial reference systems. After some time, it eventually was under the code 3857 (and there was even some other code for some time). Looking at their properties, they are the same, so you could use one ...


30

If an Esri well-known ID is below 32767, it corresponds to the EPSG ID. WKIDs that are 32767 or above are Esri-defined. Either the object isn't in the EPSG Geodetic Parameter Dataset yet, or it probably won't be added. If an object is later added to the EPSG Dataset, Esri will update the WKID to match the EPSG one, but the previous value will still work. ...


28

EPSG:4326 uses a lat/long coordinate system. Latitudes are = 90 to -90 and Longitudes are = 180 to -180 EPSG:900913 uses an x/y axis coordinate system.


25

In ol.proj.transform you need to specify the fromProjection before the toProjection, then it should work. As Michael Gentry explains in his answer, another Problem is that you have to specify the longitude (west-east thus x) first and then the latitude (south-north thus y). And a better way to set the center is to get the current view and set the center ...


24

There are three different ways to change/manipulate projections in QGIS: 1. Project Properties > CRS (or you can click on the icon where EPSG is written in the bottom right corner) This defines the proprieties of the canvas (the background layer). For exemple, if I want to display a background map from openlayers plugin (google street etc.) I will need to ...


17

Assuming your areas of interest are rather small compared to the globe, you could set up a custom transverse mercator projection. You have to know the geographic coordinates lat_0 and lon_0 of the origin of your CRS, and the direction of x and y axis: +proj=tmerc +lat_0=51.4 +lon_0=7 +k=1 +x_0=0 +y_0=0 +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs ...


15

It is a projection of a spheroid on a flat surface. Every projection has strengths and weaknesses and will preserve some elements of direction, distance or area better or worse than others (which is why careful selection of a suitable, that is local where possible, projection is so important). So, while the unit of measurement in EPSG:3857 is indeed ...


14

Your solution is a little out of date (look at Fiona - Preffered method for defining a schema). For a better solution look at that proposed by Sean Gillies in gistfile1.py to parse a delimited text file data and create a new shapefile 1) How do I define the spatial reference: Fiona crs Module from fiona.crs import from_epsg from_epsg(3857) {'init': 'epsg:...


12

Note: this is part of an answer already given here, but it seems fitting to post it again. The 6.9 means that the SRS 4326 specified in version 6.9 of the EPSG database, which you can find here.


11

There is no EPSG SRID 102743. Note that EPSG is the authority, and 102743 is the SRID. If you look up SRID 102743 on spatialreference.org, the listing is for ESRI:102743, meaning that ESRI (the publishers of ArcGIS) is the authority, not EPSG (European Petroleum Survey Group, now absorbed by the International Association of Oil & Gas Producers). The ...


11

Short Answer: QGIS handles SRS much the same as ESRI. Dive into QGIS and you'll find all your favorite SRS waiting for you. Long Answer: EPSG is the European Petroleum Survey Group. It provides 'official' spatial reference systems and spheroids and its codes are ubiquitous. ESRI takes most of its SRS from the EPSG dataset. So you are already using the ...


11

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


10

Degrees of longitude get smaller as you move away from the equator, eventually going to 0 at the poles; degrees of latitude don't suffer the same fate (looking at the latitude and longitude lines on a globe will make this clearer). Projecting your data to a coordinate system should solve the problem, because feet and meters don't change in size as you move ...


9

This appears to be documented in the SDK help, e.g. IGeometryServer.FindSRByWKID: AuthorityName is usually "EPSG" or "ESRI", but can also be an arbitrary string. It can also be the empty string if you want the default authority name associated with the new spatial reference. Clients can associate their own authority names with factory codes that are ...


9

Here's a very nice article by Alastair Aitchison describing the history of Web Mercator projection, together with all the EPSG code changes and reasons for them: The Google Maps / Bing Maps Spherical Mercator Projection. Highly recommended read.


9

You can right-click on your shapefile in the table of content, choose "save as" and define the projection system that you want as an output.


9

9820 is the EPSG code for the laea projection definition. You can find it at https://www.epsg-registry.org/ under retrieve by code. This code numer has nothing to do with the commonly used EPSG codes like 4326 and 3857. These include projection parameters specified for a certain country or region. For laea centered on Europe, the code is EPSG:3035, with ...


9

You did nothing wrong. It's just the fact that a Mercator projection can not display the south pole. The dataset you have contains a whole line at the bottom on 90°S, which can mathematically not be reprojected to Mercator. The points would be in inifinity. Easy solution is to clip the Antarctic at 89°S, i.e. remove the bottom line vertices before ...


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


9

I found the following workaround. I am unsure if it is the most efficient, but it does work for me. import gdal import osr path = r"C:\temp\test2.tif" d = gdal.Open(path) proj = osr.SpatialReference(wkt=d.GetProjection()) print(proj.GetAttrValue('AUTHORITY',1)) EDIT: Slightly more condensed


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

I have a new stack exchange account and don't have a reputation high enough to comment on the "Uncaught TypeError: Failed to execute 'putImageData' on 'CanvasRenderingContext2D': float parameter 3 is non-finite." error. This occurs because you have the lat and the long inputs backwards. map.getView().setCenter(ol.proj.transform([lat, long], 'EPSG:4326', '...


8

EPSG:31463 seems to be deprecated and EPSG:31467 is the correct one. http://spatialreference.org/ref/epsg/dhdn-3-degree-gauss-zone-3/ is stating: ProjCRS related to inappropriate coordinate system resulting in incorrect axes and name. Use EPSG:31467 instead. you can see see this, if you compare the AXIS definitions: PROJCS["DHDN / 3-degree Gauss zone ...


7

I am not sure anyy open source supports this geomagnetic to geographic. But if you are having few coordinates, pls. try this.. http://wdc.kugi.kyoto-u.ac.jp/igrf/gggm/index.html NASA has published the algorithm, you can try http://idlastro.gsfc.nasa.gov/ftp/pro/astro/mag2geo.pro


7

KML files are always WGS84/lat lon (EPSG:4326). Save the KML file as an EPSG:27700 shapefile instead. Alternatively, you could download the Ordnance Survey OpenData Boundary-Line dataset, which is already in EPSG:27700. See: https://www.ordnancesurvey.co.uk/opendatadownload/products.html N.


7

The first archive ("Roads Data - tables and layers") doesn't contain the projection information, which is pretty bad form. However, the second archive ("Roads ArcReader Projects") has the projection information in its .prj files: PROJCS["Clarke_1866_Polyconic",GEOGCS["GCS_Clarke_1866",DATUM["D_Clarke_1866",SPHEROID["Clarke_1866",6378206.4,294.9786982]],...


7

Use the gdalwarp utility. gdalwarp -s_srs epsg:4326 -t_srs epsg:3857 input.tif output.tif


7

This is a feature, not a bug. Most Leaflet users are not aware that the map's display CRS is different from the map's data CRS, and that's fine; it makes life simpler for most people. If your question would have been... I have data in EPSG:3857 but Leaflet will only accept EPSG:4326 LatLngs, how can I add my data? Then the answer would have been: You ...


7

You can also do this in one line using gdal.Info as so: epsg = int(gdal.Info(input, format='json')['coordinateSystem']['wkt'].rsplit('"EPSG","', 1)[-1].split('"')[0]) This does essentially the same thing as the answer provided by Lennert. It reads the WKT representation of the file's spatial reference, then parses the string to extract the EPSG. Note ...


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