Terrain conversion from XYZ file format to EDX .201 format

Data composed of three columns of data x (longitude), y (latitude), z (elevation) can be converted to the .201 format. The order of the data in the x and y columns (row order, column order, N to S, S to N, etc) is not important as long it remains consistent throughout the file. This means the data must be represented as a regular grid; this is one that has the same of number elements (or points) in each of the rows, ie 441 x 561 for example. The EDXCV utility examines the first 2 lines in order to determine whether it will use a row or column assignment method to create the .201 file.  Whichever columns have the same value in the first two lines, EDXCV will use that column as the "standard". If it is the Y column, EDXCV will use the row assignment method and if it is the X column it will use the column assignment method.

For example: if the X column has identical values in the first two lines, EDXCV will continue parsing that column until the value changes.  If the value changes after 2 entries, then it will use the column assignment method and now "knows" that each column will have 2 data points. In a 247,401 line data file, EDXCV starts and determines to use the column assignment method based on the fact that the first two lines in the X position are the same and every two entries after that are equal so the conversion columns will have two entries/points. The program will expect only 2 entries per conversion column going forward:

In order for the conversion to work, ALL of the remaining data in the X column must remain consistent in having 2 data points.  If there are entries that are outside of this range, the program will quit with an error message similar to the following:

If we look at the data in the XYZ file near line number 166545, we see there are a group of 16 entries for the X value of 470500 which is not consistent with the 2 points per column the utility was expecting, thus the error message:

A possible fix for this issue is to sort the X column as the primary and the Y column as the secondary and re-run the conversion to see if that resolved the issue.  In the above case, each value in the X column had 561 entries and each value in the Y column had 441 entries so the 561x441 matrix was equal to the 247,401 lines in the file. The sort did fix the issue and the conversion was able to complete successfully.

No geographic information is included in the data file and must be found through other documentation and then entered into the Geographic Parameters dialog.  This includes the selection for “linear x,y” or “geographic” horizontal units and whether data is UTM and if so, in which UTM grid zone is it from (the integer that describes the 6 degree longitudinal sector). We just need the longitude from that grid zone.  For example, gird zone 12 goes from -108 to -114 degrees, so the zone mid-point would be -111 degrees and can be inserted in the Reference Longitude field in the EDXCV Geographic Parameters dialog box.

Make sure to identify the source file information such as x,y meters or latitude/longitude.

 NOTE: One other issue that can occur is if the X and Y values are inadvertently reversed so that the longitude (X) values are in the B column and the latitude (Y) values are in the A column as shown below. The conversion will run and complete successfully, but the resulting .201 terrain file will not be formatted correctly and will not be located at the correct coordinates on the map. It is important to verify that the longitude and latitude entries are in the correct columns.