Wiki-NormOlsen at 17:42, 5 November 2009

2009-11-05T17:42:07Z

Wiki-NormOlsen: Keep it easy to use.

2009-11-05T17:36:44Z

Keep it easy to use.

New page

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 traget 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!!!

@@ Line 1: / Line 1: @@
-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:
+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.
+a&gt; 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 traget CRS.  THe test application again simply extracts three values and uses then as is in the order provided in the test database.
+b&gt; 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.
+c&gt; 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:
+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:
-D Coordinate Conversion
+*2D Coordinate Conversion
-D Coordinate Conversion
+*3D Coordinate Conversion
-Geoid Height Determination
+*Geoid Height Determination
-Vertical Datum Shift
+*Vertical Datum Shift
-Grid Scale factor (meridional and parallel)
+*Grid Scale factor (meridional and parallel)
-Convergence Angle
+*Convergence Angle
-Datum Shift Calculation
+*Datum Shift Calculation
-Geocentric Calculations
+*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.
+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!!!

Talk:Standard MetaCRS Test Data Files - Revision history

Wiki-NormOlsen at 17:42, 5 November 2009

Wiki-NormOlsen: Keep it easy to use.