Version2

[andyferris]

Updated interface for Geodesy.jl. Includes new CRS and Position types, which include possibly data-rich datums to assist in transformation via geotransform().

[andyferris]

@c42f @PaulBellette @awbsmith

[awbsmith]

Hey guys, I found some time to have a look at this. I really like having a CRS type, but I think the Position type should use a CRS as the template parameter. I'm worried we've shifted the CRS vs a point defined by a CRS notation problem, to a CS vs a point in a CS notation problem. I see this manifesting when we want to use an identifier for a CRS (an SRID) rather than the CRS itself. We don't want to have to know the CS and datum for it, just let libproj worry about what "stuff" the SRID actually describes behind the scenes.

Maybe a better way to express the above is looking at the data structure picture, I don't think a point should be a subtype of a coordinate system, it should be something separate.

My Julia fu is a little light understanding the CRS type; can you use a value type as the datum parameter? e.g. an ellipse instead of a tag for an ellipse? I'm not sure what that means for instantiating the datum field.

I'm also hoping that at some point an
immutable Position{CRS} ....
could be extended to:
immutable Position{CRS, T <: Real} ....
without things getting too ugly

Lastly, can we do Lon Lat order?

[andyferris]

Thanks Andrew.

Regarding the (second) last point, as it is currently structured, I would have LLA{T <: Real}, etc, and that would flow through automatically to Position{LLA, Datum}, etc. In principle its a great idea, and in practice it makes things a little more wordy (think Complex{Float64} ::shudder:: ).

I am thinking hard about what you say about coordinate systems vs coordinates vs SRID, etc, and hoping something sensible can be resolved.

As a workaround, it should be easy enough to define functions that go from SRIDs to their datum and coordinate system types. That should facilitate loading from files. The datum could just be something Proj4 can interpret - even a Julia singleton. But the coordinate system has to at least know the number and types of coordinates, similarly as we need to know what to load from the file (is it a 3D position? A 2D map projection? Maybe one could imagine bundling UTM coordinates and their zone as an Int, or include a time coordinate? etc...)

Lon-Lat or Lat-Lon? I dunno... I can see pluses and minuses. Perhaps two types, LatLon and LonLat, but what is LLA?

Andy

[c42f]

Let's move this discussion to JuliaGeo, it'll be lost otherwise.

I hope I'll have time to make more in depth comments over there. My main concerns at the moment are

• Abuse of the term Datum (it's much more like a CRS)
• Strange inversion of high and low level APIs - I feel like dealing with the everything-is-data Position types is a low level concern; at a high level it'd be nice to talk in terms of ENU, ECEF, and LLA with the details of the CRS in the background rather than front and centre.