Add handling of GeoDoubleParams, GeoAsciiParams to GeoKeyDirectory

[jo-chemla]

Fixes #476 (comment)

This GeoTIFF spec by maptools was a very important resource to understand these ascii and double tags and how they relate to GeoKeyDirectory
Note I have added both

• handling of DOUBLE GeoKeys
• but also extended ASCII Geokeys so not only GeogCitationGeoKey gets parsed

Also, I later decided to build the offsets object when adding type-filtered keys to the GeoDoubleParams, GeoAsciiParams structures, to avoid recomputing them afterwards when adding to GeoKeyDirectory.

EDIT: also managed to import test-data - on a windows machine, had to rework some wget/unzip and gdal commands - and added a test to geotiffwriter spec, only for the case I added of DOUBLE/ASCII parsing.

[jo-chemla]

Took another pass and decided to process the geoKeys in one single for-loop pass rather than building GeoKeyDirectory, GeoAsciiParams, GeoDoubleParams each in its own loop. Re-tested (npm run test) + with my use-case and this fixes the issue mentioned in linked issue thread.

I'm not entirely sure how to handle the case when the user wants to provide any one of GeoKeyDirectory, GeoAsciiParams, GeoDoubleParams, and am just rebuilding them if not already passed to writeArrayBuffer. I think this is ready to merge after review!

[constantinius]

@DanielJDufour Could you take a look please?

[jo-chemla]

Thanks for forwarding! Note I used the spec, and useful example from maptools doc to build the GeoKeyDirectory, GeoAsciiParams, GeoDoubleParams directories storing Ascii and Double params and Directory (which includes references as well as shorts). Don't hesitate if you have any questions regarding implementation!

[DanielJDufour]

Hi, I'm reviewing this now.

[DanielJDufour]

@jo-chemla , could you provide a little more background on why this was necessary? I'm assuming it's a floating-point arithmetic thing, but would love to know a little more details. What part of the code do you think is causing this? Thank you!

on somewhat personal note: I've spent more time than I care to admit dealing with floating point arithmetic issues in the geo space, so I prefer it there's a way to preserves numbers while round-tripping that would be awesome!! It'll definitely save later downstream confusion.

[jo-chemla]

It was actually not necessary, just switched these lines from closeTo to equal. JS only uses double precision numbers, so it indeed looks like round-tripping does preserve these numbers!

expect(geoKeys.GeogSemiMajorAxisGeoKey).to.equal(6378137.0);

[DanielJDufour]

Hey, @jo-chemla . This PR looks awesome!! It definitely improves the writing functionality a lot. I just left one minor question/comment. Just double checking on something.

[jo-chemla]

Thanks for getting back and the comment, I've resolved it - you were right, the test can be a simple equal even for the double geoKeys. Should be ready to merge from my point-of-view!

[DanielJDufour]

Approved!