Skip to content

Commit 6ae9eb3

Browse files
committed
Merge branch 'master' of https://github.com/go-spatial/proj
2 parents 043135c + 01a2c04 commit 6ae9eb3

27 files changed

+324
-447
lines changed

README.md

Lines changed: 83 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -4,38 +4,103 @@
44
[![Godoc](http://img.shields.io/badge/godoc-reference-blue.svg?style=flat)](https://godoc.org/github.com/go-spatial/proj)
55
[![license](http://img.shields.io/badge/license-MIT-red.svg?style=flat)](https://github.com/go-spatial/proj/blob/master/LICENSE.md)
66

7+
78
# proj: PROJ4, for Go!
89

9-
This project is **UNDER ACTIVE DEVELOPMENT** and is, therefore, **NOT STABLE**, which subsequently means it **SHOULD NOT BE USED FOR PRODUCTION PURPOSES**.
10+
Proj is a _selective_ and _on-going_ port of the venerable PROJ.4 project to
11+
the Go language.
1012

11-
Contact `mpg@flaxen.com` if you'd like to help out on the project.
13+
We do not intend to port all of PROJ.4: there is stuff in PROJ.4 that we'll probably never have a sufficient justification for bringing over. Likewise, we do not intend to do a verbatim port of the original code: naively translated C code doesn't make for maintainable (or idiomatic) Go code.
1214

1315

14-
# Guiding Principles and Goals and Plans
16+
# Installation
17+
18+
To install the packages, preparatory to using them in your own code:
19+
20+
> go get -U github.com/go-spatial/proj
21+
22+
To copy the repo, preparatory to doing development:
23+
24+
> git clone https://github.com/go-spatial/proj
25+
> go test ./...
26+
27+
See below for API usage instructions.
28+
1529

16-
As much as we all love PROJ4, we are not going to attempt to blindly (or even blithely) port every jot and tittle of the project.
30+
# Guiding Principles and Goals and Plans
1731

1832
In no particular order, these are the conditions we're imposing on ourselves:
1933

2034
* We are going to use the PROJ 5.0.1 release as our starting point.
2135
* We will look to the `proj4js` project for suggestions as to what PROJ4 code does and does not need to be ported, and how.
22-
* We will be "DONE" when the targetted test cases from PROJ are passing, including both direct invocations of the coordinate operations and proj-string tests.
23-
* The coordinate operations are going to be ported pretty directly, but the function signatures and "catalog" will be idiomatic Go.
24-
* The `proj` command-line app will be ported and will be idiomatic.
25-
* All code will pass [the Go `metalinter`](https://github.com/alecthomas/gometalinter) cleanly all the time.
26-
* Unit tests will be implemented for pretty much everything, using the "side-by-side" `_test` package style.
27-
* Tests will be extracted from the various PROJ tests into idiomatic Go test cases. We will not port the new PROJ test harness.
36+
* We will consider numerical results returned by PROJ.4 to be "truth" (within appropriate tolerances).
37+
* We will try to port the "mathy" parts with close to a 1:1 correspondence, so as to avoid inadvertently damaging the algoirthms.
38+
* The "infrastructure" parts, however, such as proj string parsing and the coordinate system classes -- _I'm looking at you, `PJ`_ -- will be generally rewritten in idiomatic Go.
39+
* The `proj` command-line app will not be fully ported. Instead, we will provide a much simpler tool.
40+
* All code will pass muster with the various Go linting and formatting tools.
41+
* Unit tests will be implemented for pretty much everything, using the "side-by-side" `_test` package style. Even without testing all error return paths, but we expect to reach about 80% coverage.
42+
* We will not port PROJ.4's new `gie` test harness directly; we will do a rewrite of a subset of it's features instead. The Go version fo `gie` should nonetheless be able to _parse_ all of PROJ.4's supplied `.gie` files.
2843
* Go-style source code documentation will be provided.
2944
* A set of small, clean usage examples will be provided.
3045

3146

32-
# Project Layout
47+
# The APIs
48+
49+
There are two APIs at present, helpfully known as "the conversion API" and "the core API".
50+
51+
## The Conversion API
52+
53+
This API is intended to be a dead-simple way to do a 2D projection from 4326. That is:
54+
55+
**You Have:** a point which uses two `float64` numbers to represent lon/lat degrees in an `epsg:4326` coordinate reference system
56+
57+
**You Want:** a point which uses two `float64` numbers to represent meters in a projected coordinate system such as "web mercator" (`epsg:3857`).
58+
59+
If that's what you need to do, then just do this:
60+
61+
```
62+
var lonlat = []float64{77.625583, 38.833846}
63+
64+
xy, err := proj.Convert(proj.EPSG3395, lonlat)
65+
if err != nil {
66+
panic(err)
67+
}
68+
69+
fmt.Printf("%.2f, %.2f\n", xy[0], xy[1])
70+
```
71+
72+
Note that the `lonlat` array can contain more than two elements, so that you can project a whole set of points at once.
73+
74+
This API is stable and unlikely to change much. If the projected EPSG code you need is not supported, just let us know.
75+
76+
77+
## The Core API
78+
79+
Beneath the Conversion API, in the `core` package, lies the _real_ API. With this API, you can provide a proj string (`+proj=utm +zone=32...`) and get back in return a coordinate system object and access to functions that perform forward and inverse operations (transformations or conversions).
80+
81+
_The Core API is a work in progress._ Only a subset of the full PROJ.4 operations are currently supported, and the structs and interfaces can be expected to evolve as we climb the hill to support more proj string keys, more projections, grid shifts, `.def` files, and so on.
82+
83+
For examples of how to sue the Core API, see the implementation of `proj.Convert` (in `Convert.go`) or the sample app in `cmd/proj`.
84+
85+
86+
# The Packages
87+
88+
The proj repo contains these packages (directories):
89+
90+
* `proj` (top-level): the Conversion API
91+
* `proj/cmd/proj`: the simple `proj` command-line tool
92+
* `proj/core`: the Core API, representing coordinate systems and conversion operations
93+
* `proj/gie`: a naive implementation of the PROJ.4 `gie` tool, plus the full set of PROJ.4 test case files
94+
* `proj/merror`: a little error package
95+
* `proj/mlog`: a little logging package
96+
* `proj/operations`: the actual coordinate operations; these routines tend to be closest to the original C code
97+
* `proj/support`: misc structs and functions in support of the `core` package
98+
99+
Most of the packages have `_test.go` files that demonstrate how the various types and functions are (intended to be) used.
100+
101+
102+
# Future Work
33103

34-
Packages (directories):
35-
* `proj`: the `proj` command-line tool
36-
* `operations`: the actual coordinate operations
37-
* `support`: misc stuff, including the core API
38-
* `examples`: simple yet instructive self-validating demos
104+
We need to support grid shifts, turn on more proj string keys, make the Ellipse and Datum types be more independent, port a zillion different projection formulae, the icky operation typing needs to be rethought, and on and on. Such future work on `proj` will likely be driven by what coordinate systems and operations people need to be supported: someone will provide a proj string that leads to successful numerical outputs in PROJ.4 but dies in proj.
39105

40-
The API:
41-
* ...
106+
We welcome your participation! See `CONTRIBUTING.md` and/or contact `mpg@flaxen.com` if you'd like to help out on the project.

TODO.md

Lines changed: 0 additions & 215 deletions
This file was deleted.

0 commit comments

Comments
 (0)