proj4js / proj4js

JavaScript library to transform coordinates from one coordinate system to another, including datum transformations

PROJ4JS

Proj4js is a JavaScript library to transform point coordinates from one coordinate system to another, including datum transformations. Originally a port of PROJ (then known as PROJ.4) and GCTCP C (Archive) it is a part of the MetaCRS group of projects.

Installing

Depending on your preferences

npm install proj4
bower install proj4
component install proj4js/proj4js

or just manually grab the file proj4.js from the latest release's dist/ folder.

If you do not want to download anything, Proj4js is also hosted on cdnjs for direct use in your browser applications.

Using

The basic signature is:

proj4([fromProjection, ]toProjection[, coordinates])

Projections can be proj or wkt strings.

Coordinates may be an object of the form {x:x,y:y} or an array of the form [x,y].

When all 3 arguments are given, the result is that the coordinates are transformed from projection1 to projection 2. And returned in the same format that they were given in.

var firstProjection = 'PROJCS["NAD83 / Massachusetts Mainland",GEOGCS["NAD83",DATUM["North_American_Datum_1983",SPHEROID["GRS 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],AUTHORITY["EPSG","6269"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.01745329251994328,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4269"]],UNIT["metre",1,AUTHORITY["EPSG","9001"]],PROJECTION["Lambert_Conformal_Conic_2SP"],PARAMETER["standard_parallel_1",42.68333333333333],PARAMETER["standard_parallel_2",41.71666666666667],PARAMETER["latitude_of_origin",41],PARAMETER["central_meridian",-71.5],PARAMETER["false_easting",200000],PARAMETER["false_northing",750000],AUTHORITY["EPSG","26986"],AXIS["X",EAST],AXIS["Y",NORTH]]';
var secondProjection = "+proj=gnom +lat_0=90 +lon_0=0 +x_0=6300000 +y_0=6300000 +ellps=WGS84 +datum=WGS84 +units=m +no_defs";
//I'm not going to redefine those two in latter examples.
proj4(firstProjection,secondProjection,[-122.305887, 58.9465872]);
// [-2690575.447893817, 36622916.8071244564]

The library can also parse coordinates provided with an elevation and measure, again as an object of the form {x:x,y:y,z:z,m:m} or an array of the form [x,y,z,m].

proj4(firstProjection,secondProjection,[-122.305887, 58.9465872,10]);
// [-2690575.447893817, 36622916.8071244564, 10]

If only 1 projection is given then it is assumed that it is being projected from WGS84 (fromProjection is WGS84).

proj4(firstProjection,[-71,41]);
// [242075.00535055372, 750123.32090043]

If no coordinates are given an object with two methods is returned, its methods are forward which projects from the first projection to the second and inverse which projects from the second to the first.

proj4(firstProjection,secondProjection).forward([-122.305887, 58.9465872]);
// [-2690575.447893817, 36622916.8071244564]
proj4(secondProjection,firstProjection).inverse([-122.305887, 58.9465872]);
// [-2690575.447893817, 36622916.8071244564]

And as above if only one projection is given, it's assumed to be coming from wgs84:

proj4(firstProjection).forward([-71,41]);
// [242075.00535055372, 750123.32090043]
proj4(firstProjection).inverse([242075.00535055372, 750123.32090043]);
// [-71, 40.99999999999986]

Note: The generation of the floating point value 40.99999999999986 in this example represents the fact that some variance in precision is involved in any conversion between one coordinate reference system and another.

Named Projections

If you prefer to define a projection as a string and reference it that way, you may use the proj4.defs method which can be called 2 ways, with a name and projection:

proj4.defs('WGS84', "+title=WGS 84 (long/lat) +proj=longlat +ellps=WGS84 +datum=WGS84 +units=degrees");

or with an array

proj4.defs([
  [
    'EPSG:4326',
    '+title=WGS 84 (long/lat) +proj=longlat +ellps=WGS84 +datum=WGS84 +units=degrees'],
  [
    'EPSG:4269',
    '+title=NAD83 (long/lat) +proj=longlat +a=6378137.0 +b=6356752.31414036 +ellps=GRS80 +datum=NAD83 +units=degrees'
  ]
]);

you can then do

proj4('EPSG:4326');

instead of writing out the whole proj definition, by default proj4 has the following projections predefined:

• 'EPSG:4326', which has the following alias
  • 'WGS84'
• 'EPSG:4269'
• 'EPSG:3857', which has the following aliases
  • 'EPSG:3785'
  • 'GOOGLE'
  • 'EPSG:900913'
  • 'EPSG:102113'

Defined projections can also be accessed through the proj4.defs function (proj4.defs('EPSG:4326')).

proj4.defs can also be used to define a named alias:

proj4.defs('urn:x-ogc:def:crs:EPSG:4326', proj4.defs('EPSG:4326'));

Axis order

By default, proj4 uses [x,y] axis order for projected (cartesian) coordinate systems and [x=longitude,y=latitude] for geographic coordinates. To enforce the axis order of the provided proj or wkt string, use the

proj4(fromProjection, toProjection).forward(coordinate, enforceAxis);
proj4(fromProjection, toProjection).inverse(coordinate, enforceAxis);

signatures with enforceAxis set to true:

proj4('+proj=longlat +ellps=WGS84 +datum=WGS84 +units=degrees +axis=neu', firstProjection).forward([41, -71], true);
// [242075.00535055372, 750123.32090043]
proj4('+proj=longlat +ellps=WGS84 +datum=WGS84 +units=degrees +axis=neu', firstProjection).inverse([242075.00535055372, 750123.32090043], true);
//[40.99999999999986, -71]
//the floating points to answer your question

Grid Based Datum Adjustments

To use +nadgrids= in a proj definition, first read your NTv2 .gsb file (e.g. from https://github.com/OSGeo/proj-datumgrid) into an ArrayBuffer, then pass it to proj4.nadgrid. E.g:

const buffer = fs.readFileSync('ntv2.gsb').buffer
proj4.nadgrid('key', buffer);

then use the given key in your definition, e.g. +nadgrids=@key,null. See Grid Based Datum Adjustments.

TypeScript

TypeScript implementation was added to the DefinitelyTyped repository.

$ npm install --save @types/proj4

Developing

To set up build tools make sure you have node and grunt-cli installed and then run npm install.

To do the complete build and browser tests run

node_modules/.bin/grunt

To run node tests run

npm test

To run node tests with coverage run

npm test --coverage

To create a build with only default projections (latlon and Mercator) run

node_modules/.bin/grunt build

To create a build with only custom projections include a comma separated list of projections codes (the file name in 'lib/projections' without the '.js') after a colon, e.g.

node_modules/.bin/grunt build:tmerc
#includes transverse Mercator
node_modules/.bin/grunt build:lcc
#includes lambert conformal conic
node_modules/.bin/grunt build:omerc,moll
#includes oblique Mercator and Mollweide

proj4js's Issues

documentation

• how to use it
• how to hack it
• how to extend it
• how to carve a piece off
• how to get just what you need

version 1.4.0

I merged #50 #48 and #56 into the dev branch which is taged as a prerelease version (i.e. will not satisfy any requirements unless explicitly asked for)

Trouble loading built version via AMD

I'm trying to load dist/proj4-src.js via my AMD loader (Dojo 1.8) and it's trying to load a module that doesn't exist, mgrs.js. Anyone have any ideas?

latitude error when converting ESPG:3857 to ESPG:4326 with proj4js

javascriptvar proj4 = require('proj4js'); function(pair) { var firstProjection = "+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +units=m +k=1.0 +nadgrids=@null +no_defs" var secondProjection = "+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs" return proj4(firstProjection, secondProjection, pair); }([4156404,7480076.5])

[ 37.33761240175516, 55.7832340897427 ]

But the correct values are [37.33761240175515, 55.60447049026976] — I've checked with Ruby proj4 library and http://cs2cs.mygeodata.eu/

Any ideas?

sinu transform with spherical datum

from http://trac.osgeo.org/proj4js/ticket/86

The sinu class of transformations support both elliptical and spherical datums.

Both forward and inverse transformations with spherical datums are incorrect.

I'll attach a diff to add a test using EPSG:53008 to test/testdata.js which currently fails. Correct values were determined using proj4.

patches available in the svn repo

commonjs module

make it work in node and the browser #5 brought it up.

How to convert WGS84 to Mercator.

I tried this

proj4("WGS84", "EPSG:900913", [108.80, 32.08])

and the result is [ 12111560.598308165, 3773816.457454082 ].
But if I convert all the points like this, the map can't display in the OpenLayer.
I think the problem is that I can't understand the projections.

Perhaps, to be more clear, I just want the map display like the second picture.

picture 1. Display in wgs84 projection

picutre 2. Which I want it to display like this

projection synonyms datums

currently a big stumbling block is multiple names for the same projection and obscure datums we don't have a ref for, for instance Mercator, Popular Visualisation Pseudo Mercator, Mercator_1SP, and Mercator_Auxiliary_Sphere all refer to the same thing (from our perspective) and we tend not to find out until someone tries to project a shapefile, I have a page setup http://leaflet.calvinmetcalf.com/ which will display any zipped shapefile you put in, and is a good way I've found to quickly test a weird wkt.

wkt

well known text is being complicated because as far as I can tell the esri wkt and the proj4js strings on spatial reference don't actually match up with each other

Why not version 2?

Given that 1.3 is not backwards-compatible with existing software, such as OpenLayers, would it not be better if releases were given a new major version change?

error converting from ESPG:3857 to EPSG:27700

var bngprojection = "+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000 +y_0=-100000 +ellps=airy +datum=OSGB36 +units=m +no_defs";
var pee = new proj4.Point(e.latlng.lng, e.latlng.lat);
var bngcoords = proj4(bngprojection, pee);

If I use the above code to convert a click event from the default WGS84 projection into EPSG:27700 the values I get for the longitude and latitude are about 60-100m out, on both longitude and latitude, from the same locations when I query the locations in EPSG:27700 using desktop GIS software (which I'm assuming to be correct). Do you have any ideas why this might be?

Cheers,
Mike

submit to jam

jam is a browser package manager that focuses on amd modules, we will need to add a line to the package json and then either you or I can submit it.

urn parsing

Hi, I'm working on updating Proj4Leaflet and wondering if this case is/should be still supported:

proj4.defs("EPSG:26915", "+proj=utm +zone=15 ...");
var projection = proj4('urn:ogc:def:crs:EPSG::26915');
// throws: unknown projection undefined

Looks like urn parsing was removed, I'm assuming this was for the better but wondering what the workaround should be here. The specific use case is L.Proj.GeoJSON.

add support to Proj.4 nadgrids parameter (grid based datum adjustments)

Proj.4 nadgrids parameter cannot be passed to proj4.js (at least when using it in client browser)

This is necessary for grid based datum adjustments, as described in the official Proj.4 documentation:
https://proj4.org/usage/transformation.html?highlight=nadgrids#grid-based-datum-adjustments

Example datum shift grids are available at https://proj4.org/resource_files.html#transformation-grids

If possible, it would be desirable to have the choice of loading grid files from server, client (local filesystem) and/or remote urls.

remove no-defs

the no defs versions can be removed from the dist folder, we aren't making those anymore

Tests failing in latest master

Haven't investigated this further, but I get this when running the tests:

Running "mocha_phantomjs:before" (mocha_phantomjs) task
TypeError: '[object Object]' is not a function (evaluating 'curl(['node_modules/chai/chai', 'proj4'])')

  http://127.0.0.1:8080/test/index.html:24

tests

clean up the tests and switch to a framework like mocha

Definitions

I don't know how often the projections data on trac gets updated but I updated the repo that has the tool I used to generate the defaultLocal.json https://github.com/calvinmetcalf/node-proj4js-defs if that get's updated frequently we might conciser bringing that into this repo.

camalCase

change the method names to all be JavaScript style camelCase initial lower names instead of the current mishmash of camelCase and snake_case

add a version property (svn#79)

from http://trac.osgeo.org/proj4js/ticket/79

You should add a Proj4js.VERSION variable.

It may be usefull to bypass known bugs in old versions...

Is IE8 supported?

Hi,

I am currently working on a web mapping application for an organisation keeping its members using Internet Explorer 8.

I have realised that the any of the versions hosted here are not working on IE8. The built files in the dist directory do not work with IE9 emulating IE8.
The old 1.1.0 works fine but has an inaccuracy issue on projecting web-mercator coords back to latlongs so I am a bit reticent to go on with that.

I did not find any written statements about the target browsers of this project so I would like to confirm whether IE8 is unsupported or whether there is a way to make it work on it.

support eck6 projections (svn#87)

from http://trac.osgeo.org/proj4js/ticket/87

Support eck6 projection class.

I'll add a patch that implements this support.

Note that eck6 is defined as a special case of sinu in proj4 and I've maintained that structure with this patch. This >enhancement is then dependent on http://trac.osgeo.org/proj4js/ticket/86 which details problems in the handling of >spherical datums by the sinu class.

The attached patch is cumulative, containing the changes done to make spherical sinu work properly, along with the >changes to implement and test eck6 (forcing spherical handling in all cases, consistent with proj4).

patches available from svn

A note about another Proj4js modernization project

Hi guys!
Awesome that you're looking into cleaning up Proj4js! I quietly did some work on this last fall but lack of time made me not go the last extra steps to propose the changes.
Anyway, the repo is here: https://github.com/moonlite/Proj4js if you want to have a look.

Cheers!

fix tests

I we have written the tests 3 times, I can probably re write them to only do it once.

Rename namespace back to Proj4js?

With spatialreference.org defs, the Proj4 namespace is used. And with proj4 and Proj4 being not much difference, I'd opt for renaming the namespace back to Proj4 so we're still able to load defs from spatialreference.org in script tags, and have Proj4 defined.

Opinions?

x0 and y0 defaults

I might be defining my projection incorrectly but I never considered +x_0 and +y_0 required parameters. If these are not defined they stay as undefined in the code. In my case I was going from WGS84 lon/lat to a lcc projection that didn't have these defined. When it got here it set the output x and y to NaN. Not sure why, but this didn't happen on the inverse operation.

Not sure, but this may only be a problem with lcc. I'm also not sure where the "proper" place for a fix would be otherwise I'd do it myself. Specifying the parameters in the projection definition fixes the problem.

factory function

your comment in #16 reminded me, i was thinking of turning the main proj4 function into a factory function such that you can either give it 2 projection and it returns and object with forward and reverse method or give it 3 and it projects the 3rd from the first to the second

More Extendable

from @ahocevar's list of todo's on the mainling list

Make it extensible so developers can add custom transforms, and add
custom transforms e.g. for Swiss projections, where proj4js only uses
a 3 param transform because it does not do grid transforms.

ideal vision

we really need to clean up the projection creation aspects, here is my idealized creation workflow which as 3 parts that ideally should be totally separate.

• parser: function which takes a string and turns it into a json object. This would handle parsing wkt and proj strings, and would also be where any storage of proj codes would go. The json object should be documented
• datum transformer: takes the json from step 1, or perhaps just a a single datum key, and returns a function which two methods, one for transforming to WGS84 and one for transforming from WGS84
• projector: takes the json object from step 1, passes it to the constructor for the appropriate projection and returns an object with a forward and inverse method. If possible the projections should use real constructors (aka current init method turned into the constructor) and should be able to consume the json object

There is no reason why the constructor shouldn't be able to work with a callback or a direct return.

When it comes to projecting a point the work flow should just involved more or less return datum.direction(projector.direction(point)) or possible return projector.direction(datum.direction(point))

OverloadedProj4js.js

what is the deal with this file it looks like just an ajax scriipt that we arn't using, I'd vote deleting it as if we need ajax again we can write it from scratch fairly easliy.

the amd question

Thanks for getting this started, it will be great to bring Proj4 up to speed with the modern web. My biggest interest in this process is in adding AMD support to Proj4js. I'm assuming everyone is familiar with AMD already, and perhaps already have opinions for or against it (if not, please do take a look at the RequireJS intro).

In the absence of "real" modules for the web, AMD is becoming more and more common as a way to support modular JavaScript library development (jQuery Mobile and Dojo being prominent examples). Thus, I'd argue that the question here is not whether or not to support AMD, but whether or not to integrate it directly into the Proj4js build process. I could see two overall approaches:

1. Use whatever module/build system you prefer (CommonJS, Closure, Smash...), but add the typical AMD boilerplate to the built file, so that it can be used by other projects as either a traditional "browser global" file as well or an AMD module. I'm hoping we can all agree this should be done regardless.
2. Write all of proj4js' internal modules in the AMD format, and use r.js to build the resulting file, perhaps with the boilerplate in 1. I find this option particularly compelling as it would allow me to write my project-specific code with explicit dependencies on the specific submodules in Proj4js that I need - meaning I wouldn't need a separate Proj4js build, but would just compile it as part of my app build process. This is my preferred option, but I understand that it may be less valuable to others who aren't already using AMD.

FWIW, I'm currently building a JavaScript library I call wq.app that consists only of AMD modules - I don't even have a canonical "built" distribution and don't provide any browser global variables. To get this to work without "shims" I've started maintaining AMD-compliant versions of several popular JavaScript libraries as part of my repo.

What do you think?

projection creation

re #28 and #30 I want to make it easier to make anonymous projections and to clean up the wkt parser

merc with lat_ts (svn#83)

from http://trac.osgeo.org/proj4js/ticket/83

I think there is an error in transformation from WGS84 geographical to a mercator projection with setting lat_ts parameter.

Proj4js.defs["EPSG:70212"]="+proj=merc +lon_0=0 +lat_ts=54 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84 +units=m +no_defs";
>var src = new Proj4js.Proj('EPSG:4326');
var dest = new Proj4js.Proj('EPSG:70212');

var point = new Proj4js.Point(8.4166666666,54.3);
Proj4js.transform(src, dest, point);

The calculated result with proj4js is: x=550727.0313354909 y=4227680.065624116

By using cs2cs or http://cs2cs.mygeodata.eu/ I get the following results: x=551929.429093 y=4236910.32443

change log

we probably want one, maybe only going back to version 2

automatic build system

hook this up to an automatic build system, so people can get the built version. @ahocevar did you have a particular system in mind? travis is the only one I have any experience with.

This is the long term solution to the dist issues discussed in #8

jshint

add jshint support to the build process. This would be a good place to discus what settings to use, these are all the options, a different project of mine uses the following:

bitwise:true,
camelcase:true,
curly:true,
eqeqeq:true,
immed:true,
latedef:true,
newcap:true,
noarg:true,
quotmark:'single',
undef:true,
unused:true,
strict:true,
trailing:true

of which bitwise is probably a bad idea as they are something we probably want in the library and camelcase is probably a bit of a longer term goal as there is a lot of underscores in there currently.

update osgeo trac pages & proj4js.org

I added a link to this repo from http://trac.osgeo.org/proj4js/, I suppose the other wiki pages should also be updated and/or moved here.

Host proj4.js on a CDN?

In non-npm based environments, it could be useful to use a hosted version of proj4.js. Any ideas, or a preferred free CDN that we should look into?

Projections not equivalent to proj4 C version

I may be doing something wrong here, but I can't get the proj4 js api v2.1.2 to return anything close to the correct values for a project I'm working on. The proj command line gives the correct values. The input is from a local city agency's open data which is in NAD83. The expected result lat,long is from http://en.wikipedia.org/wiki/Independence_Hall

Input X,Y: 2697359 234968
Expected output lat,long near: 39.9489 -75.1500

Command line (correct):

> echo "2697359 234968" | proj +init=EPSG:3365 +proj=lcc +lat_1=40.96666666666667 +lat_2=39.93333333333333 +lat_0=39.33333333333334 +lon_0=-77.75 +x_0=600000 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs -I -f "%.4f" -s
39.9489 -75.1500

Proj4JS (incorrect):

var proj4 = require('proj4');
var southernPennsylvania = '+init=EPSG:3365 +proj=lcc +lat_1=40.96666666666667 +lat_2=39.93333333333333 +lat_0=39.33333333333334 +lon_0=-77.75 +x_0=600000 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs';

console.log('inverseXY = ' + proj4(southernPennsylvania).inverse([2697359, 234968]));
console.log('inverseYX = ' + proj4(southernPennsylvania).inverse([234968, 2697359]));

Output:

inverseXY = -53.297795067608234,38.81762501141732
inverseYX = -84.29301165407942,62.803593428387785

Two args proj4 function fails if args are proj instances

Using the two argument version of the proj4 function appears to fail if the arguments are not strings but projection instances. Sample code:

> var firstProjection = 'PROJCS["NAD83 / Massachusetts Mainland",GEOGCS["NAD83",DATUM["North_American_Datum_1983",SPHEROID["GRS 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],AUTHORITY["EPSG","6269"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.01745329251994328,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4269"]],UNIT["metre",1,AUTHORITY["EPSG","9001"]],PROJECTION["Lambert_Conformal_Conic_2SP"],PARAMETER["standard_parallel_1",42.68333333333333],PARAMETER["standard_parallel_2",41.71666666666667],PARAMETER["latitude_of_origin",41],PARAMETER["central_meridian",-71.5],PARAMETER["false_easting",200000],PARAMETER["false_northing",750000],AUTHORITY["EPSG","26986"],AXIS["X",EAST],AXIS["Y",NORTH]]';
undefined
> var secondProjection = "+proj=gnom +lat_0=90 +lon_0=0 +x_0=6300000 +y_0=6300000 +ellps=WGS84 +datum=WGS84 +units=m +no_defs";
undefined
undefined
> proj4(firstProjection,secondProjection)    // <-- this works as expected
{ forward: [Function], inverse: [Function] }
> var fp=proj4(firstProjection)
undefined
> var sp=proj4(secondProjection)
undefined
> proj4(fp,sp)   // <-- this doesn't work
unknown projection undefined

It appears that the problem lies on lines https://github.com/proj4js/proj4js/blob/master/proj4/core.js#L20 and https://github.com/proj4js/proj4js/blob/master/proj4/core.js#L34, where the code checks if the from/to argument is instance of proj - from my quick look it seems to be false even when the argument is a projection. This causes Proj4js to handle the argument as a string, which obviously fails.

Use JSDoc3 syntax for APIdoc comments

Cannot publish 1.4.1 to npmjs.org

I tried to publish 1.4.1, because the latest on npmjs.org is 1.3.4. But when trying to do so, I get

npm ERR! publish fail Cannot publish over existing version.

error converting to belgian lambert 72

Converting to belgian lambert 72 gives an error of a couple of meters:

Belgian Lambert 72: http://spatialreference.org/ref/epsg/31370/

using the proj4 (http://spatialreference.org/ref/epsg/31370/proj4/) or wkt (http://spatialreference.org/ref/epsg/31370/ogcwkt/) both give different results:

proj4(wkt, [3.7186701465384533,51.04642936832842])
[ 104500.26176085437, 193146.49591796752 ]

proj4(proj, [3.7186701465384533,51.04642936832842])
[ 104588.1964038644, 193175.58236675244 ]

expected result:
x: 104412.34369016332, y: 193117.34979477344

More information about lambert72 (this is not my blog):

• http://jpenet.blogspot.be/2012/08/transformation-between-datums-in.html
• http://jpenet.blogspot.be/2012/08/transformation-between-datums-in_14.html

increase coverage

currently coverage status is

Statements   : 73.44% ( 2002/2726 )
Branches     : 49.71% ( 426/857 )
Functions    : 82.35% ( 140/170 )
Lines        : 73.44% ( 2002/2726 )

MGRS to WGS84 lon/lat conversion error at southern hemisphere

Conversion from an MGRS-String to lon/lat coordinates does not work properly for coordinates on the southern hemisphere.

Example to reproduce:

Take MGRS coordinate 34HBH5897707354 (approximately Cape Town) will result in coordinates near Scandinavia (while forward translation from lon/lat to mgrs works). Another example would be 56HLH3477546637 (Sydney) results in coordinates near Russia.

While several coordinates on the northern hemisphere worked, every coordinate on the southern hemisphere failed.

remove point class

internally all we really do with this beyond get the x and y variables is use it for mgrs projections. But if we're taking out mgrs projections in 3.0.0, then now there is literally no reason to have point in here. other libraries that use proj4 have their own point classes though all they really need is objects with x and y which they'd be giving it anyway.

break mgrs out into it's own repo

it doesn't share much code with the rest of the repo and seems pretty stand alone, we could step one, put it into it's own repo in a way that it can be used on it's own but require it via npm so that the api doesn't change and then next time we change major version we du

non-meter projections

looks like it's not handling non-meter projections right, this probobly has to do with spatial reference getting the proj strings wrong for them, so it being tricky for me to test them.

naming conventions

I've been having the files output as proj4.js instead of proj4js.js as I felt there isn't any reason to have the js in there twice, this is something we should probably discuss. I personally also think it wouldn't be a bad idea to have the main namespace be Proj4 not Proj4js as there is no reason (that I see) to specify it is the JavaScript port of the library inside of JavaScript. It would have the benefit of also helping to version the newer version (aka you're much more explicit errors when you try to use code meant for the old version with the new)

Modularize code further to allow optimized one-projection builds

Browsing through the code, it seems that in this state it can't satisfy an extremely common use case of making a custom build for one particular projection.

All projections share a huge "common" file, many other heavy things like "mgrs" with lots of functions for completely different cases are loaded in one monolith, many constants are defined in batch even if only a handful is used in a particular case, etc.

In a perfect Proj4.js, all the files would be split further and dependencies between different chunks defined at a small scale (which browserify makes very easy technically), which would in turn allow us to make a browserify-based build system that can make a perfect tiny build for each particular projection.

I know this has been briefly touched in #9 and #20, but since that issue was closed, I thought it would be nice to bring this up again as a clear goal.

cc @calvinmetcalf @ahocevar @sheppard