Mixed up terminology of Coords

[henriette4]

This project has an uncommon assumption regarding x/y & latitude/longitude terminology.

go-proj declares a coordinate x/y, while proj itself uses latitude/longitude and commonly x translates to longitude, y to latitude.

So if one calls NewCoord(x,y) with NewCoord(longitude,latitude), the result will be misplaced.

From the README.md one could guess that for this project it is x==latitude. But this breaks with the general assumption of x==longitude (which is not standardized properly) (gis stackoverflow discussion)

I think that also explains #13 even though I did not try to reproduce it.

[twpayne]

Thanks for opening this issue, but I don't think this is correct.

There are multiple factors:

• PROJ supports many different coordinate systems, not just those mapping to/from latitude and longitudes.
• Having NewCoord re-order its arguments is confusing and will break existing software using go-proj, i.e. changing this will require a major version bump.
• Different projections use different orders for latitude and longitude, so always flipping the order is not correct. Compare EPSG:4326 with OGC:1.3:CRS84.

Am happy to hear your further thoughts on this.

[henriette4]

I hear your arguments.

I think my point is way more shallow, since it only targets this projects variable names:

Commonly x is used to describe positions on a horizontal axis (of some sort) when used in Cartesian coordinate systems. In geographic coordinate systems longitude is used to describe positions horizontally (east/west).

If I just follow your example:

// Start with Zürich's WGS84 latitude/longitude.
zurich4326 := proj.NewCoord(47.374444, 8.541111, 408, 0)

and redo the transformation, assuming lat:=47.374444, lon:=8.541111 via epsg.io, I can reproduce your result. Easily and correct.

But, if I don't read your example carefully and only look at the signature func NewCoord(x, y, z, m float64) Coord, I would naturally insert x:=8.541111,y:=47.374444 (Since I assume x describes horizontal positions, y vertical), which would place Zuerich in Africa (epsg.io).

I didn't come here to tell you, you're doing something wrong, since your project works fine, if I accept x=lat, y=lon and stick with it. I just think that it's rather uncommon.

That's why the proposed change in #27 only renames variables locally in NewCord, but won't change anything regarding logic. Even though I didn't put in the time necessary to think this through, I assume this won't break anything, since it is only about renaming variables inside a function.

[twpayne]

Thanks for the follow-up. It's unfortunate that there is no consistency in either axis naming or axis order, and I don't think this can be fixed simply, so I think it has to be the user's responsibility to get the axis naming and order right.

[henriette4]

https://gisgeography.com/latitude-longitude-coordinates/

rust proj bindings do as I proposed.

https://gisgeography.com/latitude-longitude-coordinates/

sources like this do it as I proposed.

GIS World is pretty consistent in axis naming. So nothing unfortunate about it and it could be fixed easily. But you do you, no problem.

[twpayne]

go-proj is a thin wrapper around the PROJ library. Please raise this with the authors of PROJ. If PROJ changes its conventions then I will update this library.