# \[ANN\] CoordRefSystems.jl

**URL:** <https://discourse.julialang.org/t/ann-coordrefsystems-jl/111950>\
**Category:** Package Announcements\
**Tags:** package, announcement, geo, geodesy\
**Created:** [March 21, 2024, 8:34pm UTC](https://discourse.julialang.org/t/ann-coordrefsystems-jl/111950 "2024-03-21T20:34:49Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![ettersi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ettersi/32/6829_2.png) [@ettersi](https://discourse.julialang.org/u/ettersi)\
**Post date:** [March 27, 2024, 4:04am UTC](https://discourse.julialang.org/t/ann-coordrefsystems-jl/111950/21 "2024-03-27T04:04:37Z")

</div>

Definitely not a historian, and not a linguist either, but I wonder whether the reason for this could also just simply be that in English we like to arrange vowels in the order I, A, O (e.g. “tic tac toe” or “live laugh love”). By extension, the reason why we put latitude before longitude would then be that lat lon is easier to say than lon lat.

---

<div class="post-metadata">

**Author:** ![juliohm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/juliohm/32/215266_2.png) [@juliohm](https://discourse.julialang.org/u/juliohm)\
**Post date:** [April 2, 2024, 9:53pm UTC](https://discourse.julialang.org/t/ann-coordrefsystems-jl/111950/22 "2024-04-02T21:53:23Z")

</div>

CoordRefSystems.jl v0.1.3 has been released with all issues raised by @ettersi fixed, except for the issue on EastingNorthingUp coordinates. We will tackle it in the following months after we refactor downstream packages with real use cases.

---

<div class="post-metadata">

**Author:** ![StevenSiew](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevensiew/32/218393_2.png) [@StevenSiew](https://discourse.julialang.org/u/StevenSiew)\
**Post date:** [April 3, 2024, 12:22am UTC](https://discourse.julialang.org/t/ann-coordrefsystems-jl/111950/23 "2024-04-03T00:22:56Z")

</div>

> Blockquote  
> Definitely not a historian, and not a linguist either, but I wonder whether the reason for this could also just simply be that in English we like to arrange vowels in the order I, A, O (e.g. “tic tac toe” or “live laugh love”). By extension, the reason why we put latitude before longitude would then be that lat lon is easier to say than lon lat.

It is pure coincidende

Why is the naming convention

Firstname Familyname in Western Culture

While In Chinese Culture it is

Familyname Firstname in Chinese Culture

Why do people in USA drive on the wrongside of the road while people in UK drive on the rightside of the road?

---

<div class="post-metadata">

**Author:** ![martinmestre](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/martinmestre/32/215857_2.png) [@martinmestre](https://discourse.julialang.org/u/martinmestre)\
**Post date:** [April 3, 2024, 1:55am UTC](https://discourse.julialang.org/t/ann-coordrefsystems-jl/111950/24 "2024-04-03T01:55:52Z")

</div>

Thank you very much for your package. Does the datum/coordínate type allow to keep velocity information as well as position? If not, is it possible to extend the data types to perform full phase-space coordínate transformations if I do some reuse? I would apply to galactic dynamics. Thanks!

---

<div class="post-metadata">

**Author:** ![juliohm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/juliohm/32/215266_2.png) [@juliohm](https://discourse.julialang.org/u/juliohm)\
**Post date:** [April 3, 2024, 7:36am UTC](https://discourse.julialang.org/t/ann-coordrefsystems-jl/111950/25 "2024-04-03T07:36:50Z")

</div>

I believe that you can keep track of velocity with a wrapper type, right? What is the problem with

struct Object  
position  
velocity  
end

?

---

<div class="post-metadata">

**Author:** ![jar1](https://avatars.discourse-cdn.com/v4/letter/j/c0e974/32.png) [@jar1](https://discourse.julialang.org/u/jar1)\
**Post date:** [April 3, 2024, 7:46am UTC](https://discourse.julialang.org/t/ann-coordrefsystems-jl/111950/26 "2024-04-03T07:46:40Z")

</div>

Some writing on this topic here (from 2016):

> There’s some consensus growing around longitude, latitude order for geospatial formats, but still chaos for libraries and software.

- [List of software using each of LonLat, LatLon](https://macwright.com/lonlat/)
- [“Longitude, latitude is the right way”](https://macwright.com/2016/07/15/longitude-latitude-is-the-right-way)

---

<div class="post-metadata">

**Author:** ![juliohm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/juliohm/32/215266_2.png) [@juliohm](https://discourse.julialang.org/u/juliohm)\
**Post date:** [April 3, 2024, 8:04am UTC](https://discourse.julialang.org/t/ann-coordrefsystems-jl/111950/27 "2024-04-03T08:04:45Z")

</div>

Regarding the latlon vs. lonlat issue, that is the main reason why we didn’t use raw tuples or static vectors to represent coordinates. Instead, we defined our own structs in CoordRefSystems.jl with well-defined field names, regardless or order:

coord = LatLon(0, 0)

coord.lat  
coord.lon

Same goes for Projected coordinates, which always have fields x and y.

---

<div class="post-metadata">

**Author:** ![ettersi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ettersi/32/6829_2.png) [@ettersi](https://discourse.julialang.org/u/ettersi)\
**Post date:** [April 3, 2024, 8:34am UTC](https://discourse.julialang.org/t/ann-coordrefsystems-jl/111950/28 "2024-04-03T08:34:22Z")

</div>

Just to add my $0.02: Side-stepping the whole lat-lon vs lon-lat debate is the reason why MapMaths.jl exports both `LatLon` and `LonLat` types. In practical terms, I could imagine this being useful when you have to interact with external libraries and/or data formats, allowing you to e.g. do `LonLat(coords...)` instead of `LatLon(reverse(coords)...)`.

---

<div class="post-metadata">

**Author:** ![juliohm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/juliohm/32/215266_2.png) [@juliohm](https://discourse.julialang.org/u/juliohm)\
**Post date:** [April 3, 2024, 8:54am UTC](https://discourse.julialang.org/t/ann-coordrefsystems-jl/111950/29 "2024-04-03T08:54:41Z")

</div>

That is something that we need to assess for sure. Right now the internal design is very clean with a single set of `convert` methods between `LatLon` and other CRS. If we add a new `LonLat` just to flip the coordinates, that means that we will have to duplicate all these methods, or write some wrapper code that treats both of them equally.

Alternatively, one can consider a constructor with kwargs as in `LatLon(lon=0, lat=0)` to swap the order.

---

<div class="post-metadata">

**Author:** ![lazarusA](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lazarusa/32/6571_2.png) [@lazarusA](https://discourse.julialang.org/u/lazarusA)\
**Post date:** [April 3, 2024, 9:36am UTC](https://discourse.julialang.org/t/ann-coordrefsystems-jl/111950/30 "2024-04-03T09:36:32Z")

</div>

good one.

`If you include altitude in your position, then latitude-first gives you YXZ, which is nonsense.`

and this one:

`Almost all open source software uses longitude, latitude ordering. The only current exception is Leaflet3, which owes its ordering decision to the early-on goal of being very similar to the Google Maps SDK.`

thanks for sharing.

---

<div class="post-metadata">

**Author:** ![mihalybaci](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mihalybaci/32/13528_2.png) [@mihalybaci](https://discourse.julialang.org/u/mihalybaci)\
**Post date:** [April 3, 2024, 12:38pm UTC](https://discourse.julialang.org/t/ann-coordrefsystems-jl/111950/31 "2024-04-03T12:38:05Z")

</div>

> [@aplavin](#):
>
> I’m familiar with [SkyCoords.jl](https://juliahub.com/ui/Packages/General/SkyCoords), and it has generally been good enough for me (aside from the stalled projected coords PR).  
> Then the best approaches from both could be unified.

I think the tricky bit here is that any unification attempts go beyond matching the APIs and gets into the differences in how each discipline handles things. CoordRefSystems.jl seems to be matching PROJ, while SkyCoords.jl tries to match astropy.SkyCoords. So trying to unify the APIs within Julia them may take away the benefit of unifying between the respective Julia and Python packages. Maybe there is work under-the-hood that could be matched, but it may not make sense to alter the APIs.

> [@juliohm](#):
>
> [CoordRefSystems.jl](https://juliahub.com/ui/Packages/General/CoordRefSystems) has a much more ambitious scope.

This also makes sense because there is typically very little need for heavy coordinate system transforms in much of astronomy, no datums (data?), no altitudes, etc. (Note I’m talking astronomy, not satellite astrodynamics which is a different ballgame.)

Astronomy is also (lon, lat), it’s just called (right ascension, declination) 😉.

---

<div class="post-metadata">

**Author:** ![mike.ingold](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mike.ingold/32/203749_2.png) [@mike.ingold](https://discourse.julialang.org/u/mike.ingold)\
**Post date:** [April 3, 2024, 3:01pm UTC](https://discourse.julialang.org/t/ann-coordrefsystems-jl/111950/32 "2024-04-03T15:01:08Z")

</div>

> [@juliohm](#):
>
> If we add a new `LonLat` just to flip the coordinates, that means that we will have to duplicate all these methods, or write some wrapper code that treats both of them equally.
> 
> Alternatively, one can consider a constructor with kwargs as in `LatLon(lon=0, lat=0)` to swap the order.

I don’t have strong feelings about which ordering is allegedly superior, but once the data is encoded into a struct with named fields `lat` and `lon` there really ceases to be any concept of ordering. There doesn’t seem to be any concept of a `lonlat[1]` and, other than the constructors, I don’t see any exported functions or anything else for which ordering is relevant.

If people actually do feel strongly about constructing in a desired order, I wonder if this could be addressed with a convenience function like `LonLat(lon, lat) = LatLon(lat, lon)`. This wouldn’t require the introduction of a new type, and once created there’s little functional impact. My only hesitation with something like this is whether it introduces an unnecessary source of potential confusion since `LonLat` is really only a `Function` and not a `Type`, and can now be typo’d by a user who did intend to use `LatLon`.

---

<div class="post-metadata">

**Author:** ![Raf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/raf/32/3383_2.png) [@Raf](https://discourse.julialang.org/u/Raf)\
**Post date:** [April 3, 2024, 3:22pm UTC](https://discourse.julialang.org/t/ann-coordrefsystems-jl/111950/33 "2024-04-03T15:22:39Z")

</div>

On the lon/lat lat/lon question, EPSG codes actually specify this order - its not fixed either way in modern data sources.

Proj version 6 and onwards and R packages like sf follow this specification, but not everyone does and we are certainly not consistent with following it in julia.

So a problem we need to solve is reading/writing data from/to formats like Shapefile / GeoArrow etc and correcting the point order based on the projection.

---

<div class="post-metadata">

**Author:** ![CameronBieganek](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cameronbieganek/32/6915_2.png) [@CameronBieganek](https://discourse.julialang.org/u/CameronBieganek)\
**Post date:** [April 3, 2024, 9:06pm UTC](https://discourse.julialang.org/t/ann-coordrefsystems-jl/111950/34 "2024-04-03T21:06:04Z")

</div>

> [@mike.ingold](#):
>
> My only hesitation with something like this is whether it introduces an unnecessary source of potential confusion since `LonLat` is really only a `Function` and not a `Type`

Then maybe that function could just be called `lonlat` to be clear.

---

<div class="post-metadata">

**Author:** ![aplavin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aplavin/32/222056_2.png) [@aplavin](https://discourse.julialang.org/u/aplavin)\
**Post date:** [April 3, 2024, 9:11pm UTC](https://discourse.julialang.org/t/ann-coordrefsystems-jl/111950/35 "2024-04-03T21:11:49Z")

</div>

> [@mihalybaci](#):
>
> This also makes sense because there is typically very little need for heavy coordinate system transforms in much of astronomy

Currently, SkyCoords.jl implements n^2 transforms manually. Astropy does some fancy thing with finding any existing path in the coordinate system/transformation graph, that only requires defining O(n) transforms.  
Would be nice to have stuff like this, especially if/when then number of implemented systems grows.

> [@mihalybaci](#):
>
> no datums (data?)

Not sure if these are comparable things to Earth systems, but in astronomy there are definitely many coordinate systems that differ by some parameter – typically, indexed by a kind of a date.

> [@mihalybaci](#):
>
> no altitudes

Well, there are distances from the Earth, in addition to coordinates on the sphere. And it does make total sense to take two coordinates that include distances, and compute the actual distance between them. Sounds similar to latitude, I guess…  
SkyCoords.jl doesn’t implement this though.

---

<div class="post-metadata">

**Author:** ![mihalybaci](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mihalybaci/32/13528_2.png) [@mihalybaci](https://discourse.julialang.org/u/mihalybaci)\
**Post date:** [April 4, 2024, 12:32pm UTC](https://discourse.julialang.org/t/ann-coordrefsystems-jl/111950/36 "2024-04-04T12:32:07Z")

</div>

(Without wanting to digress too far from the OP) Yeah, there is definitely a little overlap. I have worked both in the pure astronomy realm where everything is light-years away and the pure geospatial realm where everything is tied to locations on the Earth. It just seems to me that the conventions and needs of each discipline differ enough that it may not be worth the effort to think too deeply about a unified API.

> [@aplavin](#):
>
> And it does make total sense to take two coordinates that include distances, and compute the actual distance between them.

Yeah, I could see that being a possible use.

---

<div class="post-metadata">

**Author:** ![juliohm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/juliohm/32/215266_2.png) [@juliohm](https://discourse.julialang.org/u/juliohm)\
**Post date:** [July 10, 2024, 6:18pm UTC](https://discourse.julialang.org/t/ann-coordrefsystems-jl/111950/37 "2024-07-10T18:18:32Z")

</div>

## Wish list of CRS codes

We are actively adding new CRS codes (ex: EPSG/ERSI) to CoordRefSystems.jl, and welcome suggestions from the community.

You can visit [epsg.io](http://epsg.io) to find the corresponding code of the CRS you would like to see implemented, and we will add it to new releases of the package.

We already support various popular codes as you can see here:

> <https://github.com/JuliaEarth/CoordRefSystems.jl/blob/c104d6377759ff1a3001980476754251b73fdb56/src/get.jl#L29-L44>

Please open an issue if your code is not covered yet.

---

<div class="post-metadata">

**Author:** ![juliohm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/juliohm/32/215266_2.png) [@juliohm](https://discourse.julialang.org/u/juliohm)\
**Post date:** [October 29, 2024, 5:25pm UTC](https://discourse.julialang.org/t/ann-coordrefsystems-jl/111950/38 "2024-10-29T17:25:42Z")

</div>

# CoordRefSystems.jl v0.15.1

- The `Albers` projection is now available thanks to @souma
- Increasing list of supported EPSG/ESRI codes:

> <https://github.com/JuliaEarth/CoordRefSystems.jl/blob/cf1b0d8d4a4e8ad2284cfd2c9e936bce6d64aece/src/get.jl#L60-L89>

---

<div class="post-metadata">

**Author:** ![juliohm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/juliohm/32/215266_2.png) [@juliohm](https://discourse.julialang.org/u/juliohm)\
**Post date:** [November 22, 2024, 8:04pm UTC](https://discourse.julialang.org/t/ann-coordrefsystems-jl/111950/39 "2024-11-22T20:04:22Z")

</div>

# CoordRefSystems.jl v0.16

New traits `isconformal`, `isequalarea`, `isequidistant` and `iscompromise` that can be used for automatic selection of `Projected` CRS:

```julia
isequalarea(Lambert)
isconformal(TransverseMercator)
.
.
.

```

You can learn more about `Projected` CRS in chapter 6 of the GDSJL book:

> **[6  Map projections – Geospatial Data Science with Julia](https://juliaearth.github.io/geospatial-data-science-with-julia/06-projections.html)**

---

<div class="post-metadata">

**Author:** ![evanfields](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/evanfields/32/1744_2.png) [@evanfields](https://discourse.julialang.org/u/evanfields)\
**Post date:** [November 23, 2024, 1:36am UTC](https://discourse.julialang.org/t/ann-coordrefsystems-jl/111950/40 "2024-11-23T01:36:59Z")

</div>

@juliohm Thanks for posting these updates! I somehow missed the initial release announcement but excited to see a project like this in pure Julia.

[Previous page](https://discourse.julialang.org/t/ann-coordrefsystems-jl/111950.md?page=1)

[Next page](https://discourse.julialang.org/t/ann-coordrefsystems-jl/111950.md?page=3)