Changes between Version 2 and Version 3 of CsMapRfc7
- Timestamp:
- Feb 18, 2014, 11:03:11 AM (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
CsMapRfc7
v2 v3 1 = CS-Map RFC # - NSRS2007 / NSRS 2011 Implementation=1 = CS-Map RFC # - NSRS2007 / NSRS 2011 Implementation = 2 2 3 3 This page contains an change request (RFC) for the CS-Map Open Source project. More CS-Map RFCs can be found on the RFCs page. 4 4 The change described in this request is to add support for the relatively new National Spatial Reference Systems of 2007 and 2011. These are, essentially, horizontal and vertical geodetic reference systems for the United States and its territories; produce by the National Geodetic Service of the United states. The acronyms NSRS2007 and NSRS2011 are commonly used to refer to these systems. They are also known as NAD83(2007) and NAD83(2011). 5 5 6 == Status==6 == Status == 7 7 8 8 ||RFC Template Version||(1.0)|| … … 21 21 ||no vote|| || 22 22 23 == Overview==23 == Overview == 24 24 While National Spatial Reference System 2007 )NSRS2007) has been around for several years, the shift defined by the new system, relative to the previous system (NAD83/96, aka HARN, HPGN, NAD83/91; we'll use HARN in this RFC document) was considered to small to deserve a defined shift definition. That is, the shifts were on the order of a few centimeters and at that time this was considered to be as small as the level of error. Fats forward to 2013, and precise and definitive geodetic shift models have been developed for NSRS2007. This was done at the time the US National Geodetic Survey was defining the National Spatial Reference System of 2011. Thus, at the current time, definitive models and algorithms exist for the migration of geodetic coordinates from HARN to NSRS2007 and subsequently to NSRS 2011. 25 25 26 == Motivation==26 == Motivation == 27 27 28 28 Please note that this is a sequential conversion process. That is, geodetic coordinates referenced to NAD83 must first be converted to HARN, and then converted to NSRS2007, before they can finally be converted to NSRS2011. Each of these three conversion processes has its own level of error, and each produces shifts of centimeters in magnitude. The following table indicates the ''expected'' magnitude of shifts for the three distinct datum shift calculations: … … 41 41 Please remember, you can't get to NSRS2011 without first converting to NSRS2007. So, including coverage for 49 states in three dimensions for both of the new reference systems in a distribution will require an additional 456 megabytes of data. It is indeed possible, and perhaps likely, that the data files used in these new reference systems could be ''de-densifed'' - a grid cell in all of these files is one minute by one minute; but that will have to be the subject of a new and different RFC. 42 42 43 == Proposed Solution==43 == Proposed Solution == 44 44 45 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. … … 53 53 3. writing a program to manipulate data (such as a dictionary source file) using the modified tablular data. 54 54 55 The result is a modific taion to, for example, a dictionary file which can be examined and tested. Should test results indicate, the program/table is adjusted and the modifictaion process is repeated until the modified data file (typiocally a dictionary source file) satifies the necessary requirements. In this manner, the modifications to the necessary data files are accomplished with the lowest possible probability of error, typographical or otherwise. These various programs and reulsting tables are all version controlled in the folder named ConsoleUtilities.55 The result is a modification to, for example, a dictionary file which can be examined and tested. Should test results indicate, the program/table is adjusted and the modifictaion process is repeated until the modified data file (typiocally a dictionary source file) satifies the necessary requirements. In this manner, the modifications to the necessary data files are accomplished with the lowest possible probability of error, typographical or otherwise. These various programs and reulsting tables are all version controlled in the folder named ConsoleUtilities. 56 56 57 57 Using the abovev described technique, the following chores must be accomplished: … … 66 66 * Programs which will properly match EPSG, ESRI, and CS-MAP definition names and codes need to be written. 67 67 68 Having accomplished all of the above, NSRS2007 and NSRS 2011 will have been implemented, but with one major issue remaining. 68 Having accomplished all of the above, NSRS2007 and NSRS 2011 will have been implemented, but with one major issue remaining. 69 70 === The HPGN Problem === 71 72 As indicated above, conversion from NAD83 to NSRS2007 first requires a conversion to HARN (aka NAD83/96, HPGN, NAD83/91, etc.). Conversion from NAD83 to HARN is accomplished through the use of grid interpolation files with names in the form of ''??hpgn.l?s'' where the first two characters are generally replaced with a two characetr state code. For example, two data files named ''cohpgn.las'' and ''cohpgn.los'' define the shift required to convert from NAD83 to HARN in the state of Colorado. The .las file carries the latitude shift values, while the .los file carries the longitude shift values. The cmplicating factor here is that these data file naturally overlap and the shifts carries in the overlapping files are not the same in the regions of overlap. Thus, for geography covered by the regions of overlap there are indeed two (or more) officially designated shift values. 73 74 This is why in release 13.0 of CS-MAP, the original HARN datum was replaced by some 40+ distinct datums named HARN/??. Each of these new datums essentially provided the end user with the means to address a very specific set of HPGN data files. This capability was greeted with much appreciation for those working geography in the regions of HPGN file overlaps. 75 76 With the introduction of NSRS2007, however, we now have yet another problem. At the datum shoft calculation level, we only have geographic coordinates to work with. If such geographic coordinates came from the inverse projection conversion of a state plane CRS is unknown at this level. Thus, the conversion of, say, NAD83 to NSRS2007 presents the problem of which specific set of HPGN data files should be used for any given coordinate. There is no clear, unambiguous solution to this problem. 77 78 === The 48hpgn.l?s File === 79 80 It is proposed that this problem be solved by the generation of a new ''totally unofficial'' set of HPGN files which models the NAD83 <--> HARN datum shift for all 48 conterminous states. This file to be produced using the followoing concepts: 81 * All HPGN daum shift files have a standard grid cell size of 15 minutes of latitude/longitude. 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 * 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 85 86 87 69 88 70 89
