Rework datum infrastructure

[c42f]

Originally this PR was for GDA94 and ITRF datum transformations, but it got completely out of control! I have

• Written a lot of documentation
• Reworked the datum types, adding a new abstract Datum type.
• Added a datum shift function, datum_shift_ECEF, which depends on the datum type
• Added the Dawson et al. GDA94 <--> ITRF datum transformations

---

Original comment -

Still a work in progress:

• The tests suggest something's still wrong here, needs further testing. Unfortunately I don't know of an easy source of good test data for this Australia wide. Perhaps we can get some current station coordinates from ftp://ftp.ga.gov.au/geodesy-outgoing/gnss/solutions/final/weekly/ and compare to nominal GDA94 station coordinates. May require some data munging.
• Depends on CoordinateTransformations affine transformation branch

@andyferris

[c42f]

This is pretty much good to go now - just needs a little more docs and for the affine transformations branch to be finished.

[andyferris]

See https://github.com/FugroRoames/CoordinateTransformations.jl/pull/9

[andyferris]

LVGTM

I'm noticing that so many transformations are actually constructors for other transformations. It's an interesting trend.

[c42f]

Oh, I think I've got a good idea to make the API here a lot nicer!

immutable ITRF{realization_year, EpochT}
    epoch::EpochT
end

immutable GDA94; end

# Create a transform from GDA94 to ITRF2008 at epoch 2016-1-1
trans = geocentric_datum_transform(ITRF{2008}(Date(2016)), GDA94())

# Create a transform from ITRF2008 to GDA94 which requires a time in the input coordinate (ENUt?)
trans = geocentric_datum_transform(GDA94(), ITRF{2008}())

Some nice things:

• Datums are types. I think this is "the right thing"
• A consistent way to deal with dynamic vs static datums
• We dodge the coordinate system issues by naming it in the function name ("geocentric", or maybe use ECEF)

[andyferris]

Yes, looks really good! I like all of those points about it.

So geodetic_datum_transform() could return any kind of transformation object? Like an AffineTransformation or something more complex when necessary?

[c42f]

So geodetic_datum_transform() could return any kind of transformation object?

Right exactly. And because the input Datums are types, the output will be type-inferrable. Here's another cool side effect: Suppose you wanted input and output in LLA instead. Easy!

function make_datum_transform_LLA(dest_datum, source_datum)
    LLAfromECEF(ellipsoid(dest_datum)) ∘ make_datum_transform_ECEF(dest_datum, source_datum) ∘ ECEFfromLLA(ellipsoid(source_datum))
end

[c42f]

Oh, I've been playing with naming for the main function there. Some more candidate names

geocentric_datum_transform
datum_transform_ECEF
make_datum_transform_ECEF
datum_shift_ECEF #< Maybe nice?
make_datum_shift_ECEF

[andyferris]

Yes, compositions work nicely. :)

Another way might be to let the transformation convert to ECEF it it needs to. After all, it knows what datum it is coming from and going to so there is no point in having the user defining the ellipsoid again just to come from LLA/etc.

[andyferris]

Not sure which name works best. I think it's wise to make sure it seems like a function that creates a transformation, not applies a transformation.

[andyferris]

What about datum_shift() ?

[andyferris]

What are the frames that datum shifts might occur in?

[c42f]

The best known version of a datum shift may be defined in any coordinate system. Eg for OSGB36 this is some projected coordinate system, I'm not sure about the details yet.

[c42f]

Some discussion of the ITRF vs ITRS confusion - Kovalevsky J, Mueller II, Kolaczek B (eds) (1989) "Reference frames in astronomy and geophysics" google books link

Following is probably worth a read too: "ITRF2008: an improved solution of the international terrestrial reference frame" http://dx.doi.org/10.1007/s00190-011-0444-4

[c42f]

More resources

Reference frames in practice http://www.fig.net/resources/publications/figpub/pub64/Figpub64.pdf

ITRF2008 -> earlier ITRF transformation parameters http://itrf.ensg.ign.fr/doc_ITRF/Transfo-ITRF2008_ITRFs.txt The IGN also provides a datum shift service which could be used for test data.

Article about ITRF2014 http://gpsworld.com/nasa-helps-maintain-international-terrestrial-reference-frame-with-gnss/

[c42f]

Ok, the documentation turned out to be much more effort than I expected, but I learned a lot about geodesy doing it! For now, I think I'm done.

Tests are still appearing to fail due to CoordinateTransformations (need to tag that), but work locally on 0.4.

The only thing left to do here might be figuring out what to do about passing instances vs types of Datums. It seems like instances should be the way to go, especially since some datums like ITRF seem to require that for good design, but I'm somewhat unhappy about the naming options - eg, GDA94 looks very odd to me in lowercase as gda94.

[c42f]

@andyferris I think I sorted out the Ellipsoid pretty printing problem:

julia> LLAfromECEF(GDA94())
LLAfromECEF(Ellipsoid(grs80))

julia> LLAfromECEF(Ellipsoid(grs80))
LLAfromECEF(Ellipsoid(grs80))

[c42f]

I think this is in pretty good shape now after a few final tweaks, I think everyone is on the same page with it, so I'm going to merge.

Tests still failing due to CoordinateTransformations not being tagged, but work locally.

[andyferris]

Great!

Sent from my iPhone

On 5 Aug 2016, at 2:07 PM, Chris Foster notifications@github.com wrote:

@andyferris I think I sorted out the Ellipsoid pretty printing problem:

julia> LLAfromECEF(GDA94()) LLAfromECEF(Ellipsoid(grs80))

julia> LLAfromECEF(Ellipsoid(grs80)) LLAfromECEF(Ellipsoid(grs80)) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[andyferris]

So what should we do about CoordinateTransformations? I'm thinking something along the lines of what I'm planning for Rotations: tag a 0.4-compatible version with AffineTransformation and make a seperate tag for 0.5. This will continue to propagate here, since we have some FixedVectorNoTuples... (I just spotted a mistake in the REQUIRE)

[andyferris]

Regarding my last post, would you like to tag this?

[c42f]

I'm keen to to tag CoordinateTransformations soon, but it might be worth considering settling on a couple of the API-breaking things before we do so.