Corrections for real-valued coordinates

[gwlucastrig]

I recently realized that the definition of the raster cell corner and center coordinates is not quite right. I propose to do the following

1. Rename the GvrsGeometryType enumeration to RasterSpaceType which I think better reflects what it does. I will also be moving it to Gridfour's "coordinates" package. I am doing that because I think the specification applies to raster data sets in general, not just the GVRS API. So it makes sense to move it to a Java package that has more general applicability.
2. Modify the interpretation of coordinates based on the raster-space type to be consistent with samples of source data I have investigated.
3. Update the document in GvrsFileSpecification to reflect a more accurate interpretation of behaviors
4. Extend my coordinate-transformation JUnit tests to provide more coverage of coordinates
5. Post a short article on the Gridfour wiki describing the coordinate systems in more detail.

[gwlucastrig]

Status so far... The gist of the problem is that there were certain cases at the fringe of the data domain where calculations sometimes rejected valid input coordinates. For example, in both the global-scale elevation data sets I use for my testing, a query at the North Pole would come back as "out-of-bounds" even though it was within the domain of the data set.

I've figured out an approach that does not break compatibility with data files created using recent versions of the API and am moving forward with the implementation.

Note

Any feedback on special cases that you may be concerned about would be appreciated. Good use cases are always welcome as are ideas for ways to test the GVRS API.

[gwlucastrig]

The source code changes for this issue are complete.

The details related to coordinate systems are described in the Javadoc for the GvrsFileSpecification class. The Gridfour wiki page on coordinate systems is not yet complete, but will be submitted when it is ready.

This issue is now closed.