Hot answers tagged epsg
This has been an annoying problem for a while, and hopefully will no longer be an issue. 3857 looks to be the current and correct code (I hope, that's what all my tile caches are in!). Update 9/7/11 - as noted by Vadim below in comments, Esri did in fact revert back to 102100 from 3857 at Service Pack 1. Oddly, ArcGIS Server with SP1 applied returns a ...
4326 is just the EPSG identifier of WGS84. WGS84 comprises a standard coordinate frame for the Earth, a datum/reference ellipsoid for raw altitude data, and a gravitational equipotential surface (the geoid) that defines the nominal sea level. [WP]
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.
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. ...
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 ...
After some further reading, it looks like the specifics of which orientation z values increase in depends on the specific vertical coordinate system (VCS) being used. Vertical systems oriented with 'z up' are height-based VCSes, as opposed to depth-based VCS where z is down. EPSG:5715 is an example of one such depth-based system, which when examined in the ...
If you're really going to pick a nit: EPSG 4326 defines a full coordinate reference system, providing spatial meaning to otherwise meaningless pairs of numbers. It means "latitude and longitude coordinates on the WGS84 reference ellipsoid." The term WGS84 is sometimes used the same way, but also it can refer to the ellipsoid only. For example, you can have ...
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 ...
EPSG:4236 uses a lat/long coordinate system. Latitudes are = 90 - -90 and Longitudes are = 180 - -180 EPSG:900913 uses an x/y axis coordinate system.
The tile image is already in EPSG:3857. Why not just create a world file to reference it? http://en.wikipedia.org/wiki/World_file For the tile that covers N. America at zoom 1, you'd be looking at the following worldfile contents: 78271.517 0 0 -78271.517 -19998372.6 19998372.6 Where those numbers came from: Line 1: width of an image pixel in world ...
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: ...
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 ...
The only reference I could find regarding EPSG was in the What's new in ArcGIS 10 which said Map projections and coordinate systems New coordinate systems and transformations have been added, including the following: •Definitions from the EPSG Geodetic Parameter Dataset versions 6.15 through 7.1, including 181 geographic (datum) ...
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.
The authoritative online source for information on EPSG codes is the EPSG Geodetic Parameter Registry which is powered by the EPSG dataset but is often more current than the most recent version available for direct download. According to this source, the EPSG::3785 projected CRS was initially created in response to Change Request EPSG::2008.016. This ...
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
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.
As far as I can see the two are the same thing. Our definition (in FME) is: Coordinate System Parameters CS_NAME: LL84 DESC_NM: WGS84 datum, Latitude-Longitude; Degrees DT_NAME: WGS84 EPSG: 4326 GROUP: LL MAP_SCL: 1 PROJ: LL QUAD: 1 SCL_RED: 1 SOURCE: Mentor Software UNIT: DEGREE Datum Parameters DESC_NM: World Geodetic System of 1984 ELLIPSOID: WGS84 ...
Your problem is with the bounds of EPSG:3857, the "WGS84 Pseudo-Mercator" projection. It has latitude limits of +/- 85 degrees. So your point of -85.05... is outside the bounds, and is undefined/untransformable. You'll need to use a projection that covers greater latitudes, and the choice of that will be very much based on the extents of your data, the ...
If you don't mind using an external library, Proj4js may address your requirements here. Following the UserGuide example, your destination "projection" would be 'EPSG:4326'.
The term 'projection' is often used as a synonym for the more correct term, coordinate reference system (CRS), which can include geographic and projected coordinate reference systems. When a geographic CRS is displayed in two dimensions, its angular units are treated as if they are linear--they're just displayed. They are not displayed using a Mercator ...
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 ...
It looks to me like the server is trying to validate your XML request, and failing to find the XSD that contains the definition of GetRecords. I think the EPSG sample is outdated for that server, because changing the CSW namespace to http://www.opengis.net/cat/csw/2.0.2 gets me some more errors about the Query element. Annex C of the EPSG API spec tells us ...
I have always used EPSG code 3857 for the web mercator, which is backed up by the always useful spatialreference.org. Incidentally, I could not find 900913 on spatialreference.org, but when I searched for it, one of the results it did come up with was 3857.
Latitude and Longitude can be in many projections, however in the case of the iPhone (and any other mobile device for that matter) it is most likely WGS84 coming from the device's GPS and would therefore be EPSG:4326. EPSG:900913 and EPSG:3857 are both Web Spherical Mercator projections and are based on metres and not degrees. Ordinarily you would need to ...
You can do the reprojecting with QGIS. Raster -> Projection -> Transform(Reproject) calls gdalwarp. Just select input CRS and output CRS, and a new file name.
You can seach in the EPSG geodetic parameter dataset here: http://www.epsg-registry.org/ Search for 6372 on the retrieve by code tab.
Disclosure: I'm on the subcommittee that maintains the EPSG Geodetic Parameter Dataset. I may still not correctly answer all your questions. In the EPSG parlance, a transformation doesn't have to include a change of datum. Any change is an operation. I work for Esri, and there I do differentiate and use transformation to mean a change in datum ...
check this out: I collected the information to include the projection EPSG:3857 in Oracle Spatial https://www.inf.unibz.it/dis/wiki/doku.php?id=students:minnerebner:oracle:addingsrid
For any projection different than EPSG:4326 and EPSG:900913 you need to attach the proj4js project with projection definitions
Only top voted, non community-wiki answers of a minimum length are eligible