Changes between Version 3 and Version 4 of CsMapRfc7
- Timestamp:
- Feb 18, 2014, 11:46:00 AM (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
CsMapRfc7
v3 v4 43 43 == Proposed Solution == 44 44 45 From a technical aspect of view, implementing NSRS2007 and NSRS2011 is rather straight forward. The models for these datum shifts as produced by the NGS is based on a new file format/interpolation combination which the NGS refers to as GEOCON. This format is very similar (almost identical) to previous file formats used, is that used for both horizontal and vertical NSRS datum shifts, and is also now used for the latest geoid height models produced by NGS. Adding a new grid interpolation file format named GEOCON to the repertoire which understands this new file format is relative straight forward; several standard modules are coded and the appropriate entries made in the grid file interpolation table. 45 From a technical aspect of view, implementing NSRS2007 and NSRS2011 is rather straight forward. The models for these datum shifts as produced by the NGS is based on a new file format/interpolation combination which the NGS refers to as GEOCON. This format is very similar (almost identical) to previous file formats used, is that used for both horizontal and vertical NSRS datum shifts, and is also now used for the latest geoid height models produced by NGS. Adding a new grid interpolation file format named GEOCON to the repertoire which understands this new file format is relative straight forward; several standard modules are coded and the appropriate entries made in the grid file interpolation table. These code changes can be examined by looking at CS_geocn.c and CSdataDT.c 46 46 47 47 Having made the GEOCON grid file format option available, the NSRS2007 and NSRS2011 geodetic transformations can be easily be defined in the Geodetic Transformation Dictionary by referencing the appropriate files. As Datum definitions are now simply name placeholders, the NSRS2007 and NSRS2011 datums are easy to define. … … 82 82 * Fairly definitive state boundaries are available from teh EPSG database; certainly definitive enough to predict in which state any 15 minute Lat/long coordinate resides in. 83 83 * We then establish a HPGN grid file set named 48hpgn.las and 48hpgn.los which covers the entirity of the 48 conterminous states and has a 15 minute grid cell size. 84 * For each data point in the 48HPGN dta file set: 85 * Determine the state in which the point lies 86 * Determine the specific HPGN data file set from which values are to be extracted, 87 * Extract the appropriate data values and insert into the 48HPGN data file set being created. 84 88 89 This process will succedd in generating valid coverage for most all of the 48 state geography. Problems occur where there are substantial waterways between states which are not included in the state boundary polygons; CHesapeak Bay, and the Great Lakes for example. These situation need to be detected and than manually dealt with. 85 90 91 === Additional Complications === 86 92 93 The following information will be of value to anyone reviewing the proposed changes: 94 1. There are three cases where the official HPGN data files set cover more than one state: 95 * the wohpgn.l?s data file set covers both Washington and Oregon 96 * the nehpgn.l?s data file set covers VT, NH, MA, and CT; i.e. New England (sans Maine) 97 * the mdhpgn.l?s data file set convers both Maryland and Deleware. 98 * the hihpgn.l?s files are for Hawaii, but don't overlapo anything, so there is no problem. 99 2> There are three states for which there are two HPGN data file sets: 100 * The cshpgn.l?s and cnhpgn.l?s files cover southern and northern California repectively. 101 * the emhpgn.l?s and wmhpgn.l?s files cover eastern and western Montana respectively. 102 * the ethpgn.l?s and wthpgn.l?s files cover eastern and western Texas respectively. 103 * the eshpgn.l?s and wshpgn.l?s files cover eastern and western Ammerican Samoa repectively. These files oonly overlap with themselves, and the region of overlap is all Pacific Ocean, so these file do not present a problem. 87 104 105 Of course, in the case of multiple HPGN data file sets covering a single state the files overlap, and yes the grid shift values in the regions of overlap are not the same. It is now known, for example, in the region of overlap in Montana, the differences between the two files is as much as 17 centimeters. 88 106 107 === Result Evaluation === 89 108 90 I mplications109 In regions internal to a specific state, the 48HPGN file solution produces results basically identical with the previous releases. The exact same interpolation code is used on the same data values. However, when one approaches the the boundary of any specific HPGN region (i.e. thegeography where HPGN data file overlap) the results can be as much as 10 centimeters different. 91 110 92 This section allows discussion of the repercussions of the change, such as whether there will be any breakage in backwards compatibility, if documentation will need to be updated, etc. 93 Test Plan 111 The best example of this condition is the four corneres area of the southwestern United States, a point of geography where four state borders come together and there are four different sets of HPGN data files which cover the intersection point. Thus there are four separate values of the shift at that point. The Colorado and Uath numbers, while not identical, are very close. The Arizona and New Mexico numbers are very close. Howevere, there is a 10 centimeter difference between the two sets of numbers. Who is to say which is correct? 94 112 95 How the proposed change will be tested, if applicable. New unit tests should be detailed here??? 96 Funding/Resources? 113 == Testing == 97 114 98 This section will confirm that the proposed feature has enough support to proceed. This would typically mean that the entity making the changes would put forward the RFC, but a non-developer could act as an RFC author if they are sure they have the funding to cover the change. 115 Testing of the horizontal shifting at the geodetic coordinate level (i.e. lat/longs) will be accomplished using data points generated by the NGS supplied executable geocon.exe. This program accepts input data, and produces output data, in what is known as Blue Book format. In order to facilitate the generation of test data in the form used by the CS-MAP ConsoleTestCpp program, a TcsBlueBook object has been developed and program which produce test point data in this format, and the eventually convert the Blue Book data produced by geocon.exe into the TEST.DAT form have also been written. 116 117 Generally, the results match at the +/- 2 millimeter level. Precision is difficult to maintain in this testing environment as the Blue Book format only supports five didgits of precision at the arc-second level. Thus, verifying results at that low precision value get into trying to make sure ASCII to real and real to ASCII conversions, along with conversions from/to degrees, minutes, and seconds are now all part of the verification issue. 118 119 Tests generated for inclusion in the standard TEST.DAT file used by ConsoleTestCpp do not test vertical components (a weakness which deserves attention). Thus, testing the vertical component of the NSRS2007/NSRS2011 implementation needs to be done manually. 120 121 == Implications == 122 123 The implementation as is currently being tested is maintain in the CS-MAP Subversion repository as a ''sandbox'' named NSRS2007. 124 125 This implementation leaves all of the precious HARN/?? datum shifts in place. It introduces a new datum named NAD83/HARN. The transformations referneced to this new datum are the only transformations which reference the new 48HPGN data set. End users which have the need to have a specific set of HPGN grid shift files can achieve this by simply placing an entry for the superceeding HPGN data file set ahead of the 48HPGN data file set reference in the Geodetic Transformation Dictionary. Thus, a user working in the Four Corners area of the southwest, can specificy that, for example, the Arizona datum shift values are to prevail can do so by entering a reference to azhpgn,l?s ahead of the reference to 48hpgn.l?s. Editing the Geodtic Transformation Dictionary is recognized as not being an ideal solution, but given the nature of the beast, it is the best available short of adding the possibility of user interaction required when certain coordinate conversions are selected. 126 127 == Funding/Resources == 128 129 The implementation is complete and resides in a CS-MAP Subversion ''sandbox'' named NSRS2007. Additional test cases will need to added, and the current ConsoleTestCpp TEST.DAT file does not support vertical testing; thus vertical testing will need to be done separately. Additionally, x64 and Linux testing is yet to be performed. 130 131 Funding was provided by Autodesk. Upon approval of this RFC, the proposed changes will be submitted to the trunk.
