Changes between Version 1 and Version 2 of CsMapRfc1
- Timestamp:
- Oct 27, 2008, 5:05:34 PM (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
CsMapRfc1
v1 v2 1 = CS-Map RFC 1 - Title Goes Here=1 = CS-Map RFC 1 - Creation of a GDC file to handle French grid files = 2 2 3 3 This page contains an change request (RFC) for the CS-Map Open Source project. … … 24 24 == Overview == 25 25 26 Currently, the French systems that use the datum NTF-G-Grid use the datum conversion technique RGF93 that uses a single grid file gr3df97a.txt, a choice that is hard coded inside the CS-Map code.26 Currently, the French systems that use the datum NTF-G-Grid use the datum conversion technique RGF93 that uses a single grid file gr3df97a.txt, a choice that is hard coded inside the CS-Map code. 27 27 28 28 While this single grid file covers the whole country of France there are now new grid files for the metropolitan areas of this country that offer a greater precision and there is a strong need to support these new grid files. 29 30 == Motivation == 31 32 All French cities that need to use a dedicated transformation grid file can currently not use such grid files with CS-Map. Those cities include but are not limited to: Bordeaux, Nice, Toulouse, Marseille, Nates. 33 34 == Proposed Solution == 29 35 30 36 The concept of a Geodetic Data Catalog file (.gdc) is already in use in CS-Map for the North American continent for instance, through the use of text files that list the grid files to be used for a particular datum conversion technique. The extension of these files is .gdc and the files are editable by the users to add more files, comment out a grid they don’t want to use, or change the order in which the grid files are used. The order matters only when two grid files overlap and a point is located right in this region. In this case we need to make a choice of what grid file needs to be used, this choice is made depending on the order the grid files are listed in this GDC file and other options. So, if the order is not the one that is needed, the end user can change it by just editing the text of the .gdc file. 31 37 32 38 The new IGN grid files cover only the metropolitan areas and use the NTV2 file format. 33 The new gdc file will list the existing gr3df97a.txt file and these new NTV2 grid files, knowing that more can be added as they become available. Since the redistribution of the NTV2 grid files is not allowed, the reference to these files will be commented out by default and users will have to contact the IGN to get them and then edit their copy of the gdc file to uncomment them. That means that by default the behavior will be the same as it is today. This NTV2 situation and its non-distribution is similar to the Canadian NTV2 grid file that is currently not distributed. 39 The new gdc file will list the existing gr3df97a.txt file and these new NTV2 grid files, knowing that more can be added as they become available. 40 41 == Implications == 42 43 Since the redistribution of the NTV2 grid files is not allowed, the reference to these files will be commented out by default and users will have to contact the IGN to get them and then edit their copy of the gdc file to uncomment them. That means that by default the behavior will be the same as it is today. This NTV2 situation and its non-distribution is similar to the Canadian NTV2 grid file that is currently not distributed. 34 44 35 45 Systems that use the datum NTF-G-Grid are systems like: NTF.Lambert-1, NTF.Lambert-3, NTF.Lambert-3, … 36 46 The existing grid file is used when a conversion occurs from one of these system to, for instance, Lambert93, RGF93.CC42 or RGF93.CC50 47 37 48 After the code change, and the use of the new gdc file, nothing will change at the level of the coordinate system definitions inside the dictionaries. What will decide the use of the metropolitan grid files to get a greater accuracy is the order in which the grid files will be listed in the new gdc file for these same conversions. 49 50 == Test Plan == 38 51 39 52 Test points will be provided and added to the test point file TEST.DAT and will be taken into account when the regress test is executed before each new future code submission. Since the grid files cannot be redistributed, the test points will be commented out by default in the test file. 40 53 41 == Motivation ==42 43 This is the most important part of the RFC. It describes the problem domain in detail. Focusing on this will allow reviewers to fully understand why the proposed change is being made, and potentially suggest different/better ways of accomplishing the desired results. The more time we spend on understanding the problem, the better our solution will be.44 45 == Proposed Solution ==46 47 This is a more detailed description of the actual changes desired. The contents of this section will vary based on the target of the RFC, be it a technical change, website change, or process change. For example, for a technical change, items such as files, new coordinate system definition, WKT mapping, and API chances would be identified. For a process change, the new process would be laid out in detail. For a website change, the files affected would be listed.48 49 == Implications ==50 51 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.52 53 == Test Plan ==54 55 How the proposed change will be tested, if applicable. New unit tests should be detailed here???56 57 54 == Funding/Resources == 58 55 59 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.56 Provided by Autodesk.
