derhuerst / epsg-index Goto Github PK

View Code? Open in Web Editor NEW

18.0 3.0 4.0 59 KB

A machine-readable index of all EPSG coordinate systems.

Home Page: https://github.com/derhuerst/epsg-index

License: ISC License

JavaScript 100.00%

epsg coordinate-systems wgs-84 wgs84 list

epsg-index's Introduction

epsg-index

A machine-readable index of all EPSG coordinate systems. Similar to epsg and node-proj4js-defs, but kept up to date (so far). Like python-epsg, but in JavaScript/JSON.

Installing

npm install epsg-index

Usage

// use import assertions once they're supported by Node.js & ESLint
// https://github.com/tc39/proposal-import-assertions
import {createRequire} from 'module'
const require = createRequire(import.meta.url)

const epsg4326 = require('epsg-index/s/4326.json')

console.log(epsg4326)

{
	code: '4326',
	kind: 'CRS-GEOGCRS',
	name: 'WGS 84',
	wkt: 'GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4326"]]',
	proj4: '+proj=longlat +datum=WGS84 +no_defs',
	bbox: [90, -180, -90, 180],
	unit: 'degree (supplier to define representation)',
	area: 'World.',
	accuracy: null
}

You can also load all coordinate systems (5mb of data):

const all = require('epsg-index/all.json')

console.log(all['4326'])

transform-coordinates – Transform coordinates from one coordinate system to another. Built on top of epsg-index.
python-epsg – A Python API to the EPSG Geodetic Parameter Dataset.

Contributing

If you have a question or have difficulties using epsg-index, please double-check your code and setup first. If you think you have found a bug or want to propose a feature, refer to the issues page.

epsg-index's People

Contributors

Stargazers

Watchers

Forkers

yuzhiyao jingasan yonda-yonda

epsg-index's Issues

switch to epsg.org as data source?

The collection of parameters harvested from epsg.io results in parameters that give incorrect results when used in conjunction with proj4JS. The CRS data published at spatialreference.org seems to be more reliable in this regard.

For now it is only anecdotal evidence, but I have identified two cases where this causes incorrect results when using epsg-index:

EPSG:2169

https://epsg.io/2169 gives as a proj4 definition:
+proj=tmerc +lat_0=49.8333333333333 +lon_0=6.16666666666667 +k=1 +x_0=80000 +y_0=100000 +ellps=intl +towgs84=-265.8867,76.9851,20.2667,0.33746,3.09264,-2.53861,0.4598 +units=m +no_defs +type=crs

https://spatialreference.org/ref/epsg/2169/ gives:
+proj=tmerc +lat_0=49.83333333333334 +lon_0=6.166666666666667 +k=1 +x_0=80000 +y_0=100000 +ellps=intl +towgs84=-193,13.7,-39.3,-0.41,-2.933,2.688,0.43 +units=m +no_defs

(note the diverging towgs84 parameter!)

The latter one seems to be correct, see this thread on Mastodon for the feedback of someone with local knowledge: https://mapstodon.space/@jaykayone/111325366362650226

Simplified test case here: https://observablehq.com/d/841eca8097085b5d , with the definition from spatialreference.org giving the correct result.

EPSG:4312

https://epsg.io/4312 :
+proj=longlat +ellps=bessel +no_defs +type=crs

https://spatialreference.org/ref/epsg/4312/ :
+proj=longlat +ellps=bessel +towgs84=577.326,90.129,463.919,5.137,1.474,5.297,2.4232 +no_defs

Again, the latter one is correct, as the first one is missing the crucial towgs84 parameter.

I have no idea what is going on here, or how to reach the maintainers of epsg.io, but these (admittedly anecdotal) data points strongly suggest that epsg.io cannot be trusted as a source for CRS info.

Switching to the data from spatialreference.org should be easy, as the URL pattern https://spatialreference.org/ref/epsg/{epsg_code}/proj4/ will get a text-only response with the proj4 definition.

An in-range update of qs is breaking the build 🚨

The devDependency qs was updated from `6.7.0` to `6.8.0`.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

qs is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Status Details

❌ continuous-integration/travis-ci/push: The Travis CI build failed (Details).

Commits

The new version differs by 14 commits.

57657ff v6.8.0
d1d06a6 [Dev Deps] update eslint, @ljharb/eslint-config, browserify, safe-publish-latest
649f05f [New] add depth=false to preserve the original key; [Fix] depth=0 should preserve the original key
a30e4b1 [Tests] add tests for depth=0 and depth=false behavior, both current and intuitive/intended
360ec16 [Tests] use eclint instead of editorconfig-tools
b14b638 [Dev Deps] update eslint, iconv-lite, browserify, tape
82c4a5f add github sponsorship
4a1cf05 readme: add security note
a07882f add FUNDING.yml
3b40167 [Fix] ensure node 0.12 can stringify Symbols
14c69e6 Clean up license text so it’s properly detected as BSD-3-Clause
2ebaf87 [New] [Fix] stringify symbols and bigints
faeab53 [Refactor] formats: tiny bit of cleanup.
8dbad28 [Fix] fix for an impossible situation: when the formatter is called with a non-string value

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

Your Greenkeeper Bot 🌴

An in-range update of pinkie-promise is breaking the build 🚨

Version 2.0.2 of pinkie-promise was just published.

Branch	Build failing 🚨
Dependency	pinkie-promise
Current Version	`</td>`
Type	devDependency