Talk:Standard MetaCRS Test Data Files

One of the two or three PRIMARY goals of this project is to produce a file which will be used. If we make it a significant project to just to parse the data and use the test results, it will not get used. In this regard:

Coordinates for the test cases are:

a> Always in the order defined by the related CRS. This applies to both the source and target coordinates; order and units. Thus, the test application does not need to jump through hoops determining what the CRS requires and then figure out what the test case is providing. The test application simply extracts the source and target values and uses them as is in the order provided.

b> The tolerance values (order and units) are treated the same way, and always in relation to the target CRS. The test application again simply extracts three values and uses then as is in the order provided in the test database.

c> Formatting of the coordinates is a tricky problem, but we must choose something that makes it easy for a test application developer to use the data file. We should support two or three simple numeric formats. Obviously a pure signed decimal number is one and degrees, minutes, and seconds in a format for which the probablility of a generic parsing function is most likely. For obvious reasons, I like the form supported by CS-MAP, but that might not be the most usable for an application written in Java or Python. To the degree that code exists to parse DMS, we should use the most widely supported format so as to make it as easy as possible for a test application developer to use the data file.

I would also like to see a "Test Type" field. The following is a short list of the types of tests I'd like to incorporate into the file:

• 2D Coordinate Conversion
• 3D Coordinate Conversion
• Geoid Height Determination
• Vertical Datum Shift
• Grid Scale factor (meridional and parallel)
• Convergence Angle
• Datum Shift Calculation
• Geocentric Calculations

The function of the ordinate fields in each test type would/could be slightly different. Specific test types would simply ignore fields which it does not need, and those fields simply left empty by the originator of the test. Generally, the first four value fields would be reserved for the source information and the second four fields reserved for the target values, and a thrid set of four fields reserved for tolerance information.

Four fields as mention immediately above might be overkill right now, but we are already encountering the problem of not only knowing where something is, but when was it there!!!