| | 135 | |
| | 136 | == Implementation Notes == |
| | 137 | |
| | 138 | Implementation of this RFC produced the following items for which additional documentation needs to be provided. |
| | 139 | |
| | 140 | === NSRS Datum Shift File Naming Convention === |
| | 141 | |
| | 142 | As described below, NSRS datum shifts rely on datum shift data files in the GEOCON format. Definitions of Geodetic Transformations need to specify where such files are located and which specific files apply to individual transformations. Additionally, a geodetic transformation needs to be able to access three such data files. The official data files provided by the National Geodetic Survey (NGS) have the names indicated in the following table: |
| | 143 | |
| | 144 | || Region || Datum || Longitude Shift || Latitude Shift || Vertical Shift || |
| | 145 | || US 48 States ||NSRS 2007 || dslo.b || dsla.b || dsv.b || |
| | 146 | || Alaska ||NSRS 2007 || dsloa.b || dslaa.b || dsva.b || |
| | 147 | || Puerto Rico & VI ||NSRS 2007 || dslop.b || dslap.b || dsvp.b || |
| | 148 | || US 48 States ||NSRS 2011 || dslo11.b || dsla11.b || dsv11.b || |
| | 149 | || Alaska ||NSRS 2011 || dsloa11.b || dslaa11.b || dsva11.b || |
| | 150 | || Puerto Rico & VI ||NSRS 2011 || dslop11.b || dslap11.b || dsvp11.b || |
| | 151 | |
| | 152 | Within the file name, clearly it is the 'o', 'a', and 'v' letters that identify the function of the specific file with respect to the transformation. Thus, a naming convention has been adopted where the file name portion of a grid data reference shall contain a "l?" character sequence. In order to get access to the appropriate data files, the GEOCON transformation constructor will replace the '?' character in the specified file name sequentially with 'o', then 'a', and then replace the complete "l?" sequence with a single 'v' character in order to locate and open the appropriate files. Thus, a file name of "dsl?.b" would be used to reference the three file set: "dslo.b", "dsla.b", and dsv.b". Otherwise, the files can be named anyway developers and/or users want, as long as the Geodetic Transformation dictionary entries adhere to the simple "l?" convention. (If the 'l' character is upper case, the inserted character will also be upper case.) |
| | 153 | |
| | 154 | Typically, these files are maintained in the "Dictionaries/USA/NSRS2007" and "Dictionaries/USA/NSRS2011" directories, but this is not required. They can be located anywhere on the system (or network) where a standard "fopen" can access them. |
| | 155 | |
| | 156 | === GEOCON Data File Size === |
| | 157 | |
| | 158 | All of these files have a grid density of one minute. Thus, the files are huge, on the order of 20 megabytes. As indicated above, the GEOCON paradigm requires at least two data files (for horizontal transformations), and usually a third (for the vertical component). There are three geographic area covered (with more to come?). Further, there are two separate datums to support. Thus, all tolled, there are approximately 300 megabytes of grid shift data here, and its all binary that does not compress very well. Including 300 megabytes of data for a seldom used (as yet, anyway) feature in distributions and check out downloads is unacceptable. I suggest two alternatives to this problem, a combination of the two could also work. In either case, an RFC depicting the exact solution methodology would need to be presented and approved. |
| | 159 | |
| | 160 | ==== First Alternative ==== |
| | 161 | Do not include the data files in the distribution, or even in the Subversion repository. Release documentation should indicate that the distribution does not include these files and provide information on how they can be obtained. The distribution should install the directories which would normally hold these files and place there an extensive README.TXT file with similar information. Upon first access to an NSRS datum, an error condition would lead the user to this information. |
| | 162 | |
| | 163 | ==== Second Alternative ==== |
| | 164 | Each of the GEOCON data files is based on a one minute by one minute grid; an incredible density level. Even for entirety of Alaska, the density is one minute by one minute. A program could be written to convert these data files to a density of 3x3 which would reduce the size of the file by almost 90%. The degree of error would be rather small. Users could always replace the lower density files with the real files should they feel the need. Conversions using the less dense files might be a tad faster. |
| | 165 | |
| | 166 | === NAD83 to HARN Conversions === |
| | 167 | |
| | 168 | Geodetic transformations from NAD83(1986) to HARN require the use of grid data shift files of the "??hpgn.l?s" variety. There are about 45 different sets of these files, usually one set per state (there are variations). When asked to convert from NAD83 to HARN, CS-MAP typically knows which set of files to use as there are some 45 different HARN datums (obviously one datum defined for each set of grid data files). If CS-MAP is asked to convert from NAD83 to NSRS2007, it must first convert the NAD83 coordinates to HARN. But which specific HARN is it to use to do the conversion? Generally, at the geodetic transformation level, there is no knowledge of the geography involved, or the Cartesian system from which the geographic coordinates were generated. |
| | 169 | |
| | 170 | This is complicated by two considerations. First, CS-MAP has no facility to query the end user for information as to which set of HPGN files are to be used. Second, CS_MAP has always been able to convert from any defined coordinate system to any other defined coordinate system without any user interaction. |
| | 171 | |
| | 172 | The solution implemented to address this problem is the development of an aggregate HPGN file set named "48hpgn.l?s". This aggregation was accomplished using the state boundaries contained in the EPSG Parameter Dataset to build a grid with points from the appropriate "??hpgn.l?s" data set. This generally produces the correct results. There are problems due to the fact that the 45 sets of HPGN grid data files all overlap their neighbors to some extent, and the information in the areas of overlap are not the same. Thus, in regions close to the coverage boundaries of the various 45 data sets, the results can be different from what an end user might otherwise expect. This possibility must be documented. |
| | 173 | |
| | 174 | There are three possible work a rounds to this problem. First, end users can use Geodetic Paths to specify the specific HARN datum they want a specific transformation to go through. This implies that Geodetic Paths may need to be changed frequently, and there is the possibility that a necessary change is omitted and erroneous results go undetected. |
| | 175 | |
| | 176 | Second, the Geodetic Transformation definition for the NAD83/HARN datum can be edited so that an original "??hpgn.l?s" data set is given priority over the aggregate HPGN file. Thus, a consulting shop which works primarily in Arizona could modify the geodetic transformation file putting the "azhpgn.l?s " data file ahead of the agggregate data set. Thus, the Arizona data set would always supersede the aggregate data set and the expected results will be obtained. |
| | 177 | |
| | 178 | Third, it could be that we should enable client applications to register a callback function with CS-MAP so that in the event of a situation where CS-MAP needs help deciding what to do, user interaction is possible. In the case of converting from NAD83 to NSRS2007 the callback function would be used to get a selection from the user as to which set of HPGN data files are to be used for the NAD83 to HARN conversion. (This is the approach Brand X is considering.) |
