Hot answers tagged epsg
31
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 ...
20
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]
16
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.
...
14
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.
13
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 ...
12
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 ...
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 ...
7
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 ...
6
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 ...
6
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)
...
6
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 ...
5
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.
5
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 ...
5
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
...
5
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 ...
5
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
4
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 ...
4
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 ...
3
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 ...
2
I believe that the issue that you are seeing is the result of proj4 (the projection engine behind gdal/mapserver) is not doing the datum transformation for you. This is likely because there are several options for data transforms between 23031 and WGS84 and proj.4 no longer defaults to one of them.
Take a look at this explanation:
...
2
EPSG:900913 (which is deprecated, you should really be using its modern synonym EPSG:3857) is a projected CRS, not lon/lat. So if you want a spherical mercator result, you'll need to transform from lon/lat to EPSG:3857, skipping EPSG:27700 completely.
Or if your getLonLatFromPixel() results are in EPSG:27700, you'll need to use EPSG:4326 as your ...
2
GWC doesn't do reprojection, so you need to
download GeoServer 2.1 and set up your remote WMS as a cascading WMS, GeoServer will then reproject your remote WMS from 4326 to what ever projection you need. Then use the built in GWC to serve out tiles from the cascaded layer.
This blog post ...
2
In case you want your mapserver to provide WMS layer, which is reprojected on the fly you will require GDAL to be configured with your MapServer. If you are on windows a simple solution is installing MS4W. Now your mapfile definition could be as simple as follows:
MAP
NAME USA
STATUS ON
SIZE 800 500
IMAGETYPE PNG
...
2
This is what, SLD99/Sri Lanka Grid 1999? As mentioned, you'll have to define a custom CRS for this. The parameters I have are as follows:
+proj=tmerc +lat_0=7.000471527777778 +lon_0=80.77171308333334 +k=0.9999238418 +x_0=500000 +y_0=500000 +a=6377276.345 +b=6356075.41314024 +towgs84=-0.293,766.95,87.713,0.195704,1.69507,3.47302,-0.039338 +units=m +no_defs
...
2
The links provided by vadivelan make it clear that geomagnetic coordinates are just a rotation of the sphere so that (a) the north pole passes through the current magnetic south pole and (b) the prime meridian passes through the physical and magnetic poles.
For instance, IGRF-95 uses the position of the magnetic north pole in 1995, at latitude 79.30 and ...
2
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.
2
You could add a custom SRID in a spatialite database (adding a row into spatial_ref_sys table), with a simple request, but here, it looks like the CRS you want to add (based on the information you give ) is already in the database :
It's SRID/EPSG 3814/3815/3816 (they all looks like the same to me :/).
HTH.
2
it depends on the Version of Qgis Lisboa you use.
There is a bug in Qgis standalone installer for Windows which prevents the synchronisation of Qgis own CRS database with that of Gdal, if the installation path contains blanks (which is default). The Osgeo4w Installer does it correct by now, and supplies EPSG:3814 from GDAL to qgis:
+proj=tmerc +lat_0=32.5 ...
2
CSRS stands for the Canadian adoptation of NAD83:
http://www.geod.nrcan.gc.ca/userguide/guideline/guideline4/guideline4a_e.php
In fact, there are several projections with identical definitions. Some of them are intended to reflect tectonic moves, but usually this is not yet implemented in GIS software.
1
The following should work, but for me the output file is always zero length (on Windows, the output redirection works fine on Linux).
gdaltransform -s_srs EPSG:26986 -t_srs EPSG:4326 < in.txt > out.txt
Where in.txt contain a line separated list of space separated coordinate pairs. If you remove the > out.txt you'll see the list of transformed ...
Only top voted, non community-wiki answers of a minimum length are eligible
