CS-Map RFC 3 - EPSG/SRID Code Upgrade
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.
Status
| RFC Template Version | (1.0) |
| Submission Date | 21 June 2010 |
| Last Modified | Norm Olsen 21 June 2010 |
| Author | Norm Olsen |
| RFC Status | draft |
| Implementation Status | pending |
| Proposed Milestone | 13.01 |
| Assigned PSC guide(s) | (when determined) |
| Voting History | (vote date) |
| +1 | |
| +0 | |
| -0 | |
| -1 | |
| no vote |
Overview
Propose to add the EPSG code and the Oracle SRID code to the Coordinate System Definition structure (cs_Csdef_). Also propose to add the EPSG code to the Datums Definition structure (cs_Dtdef_) and the Ellipsoid Definition structure (cs_Eldef_). These data items will be inserted in the appropriate dictionary .asc files with values currently known to the NameMapper.
Also propose that the EPSG axes orientation information, in the form of a CS-MAP "Quad" code, be added to the Coordinate System Definition structure (cs_Csdef_). This value will be added to the dictionary .asc file with values extracted from the EPSG Parameter Dataset version 7.05.
Motivation
Mapping large portions of the EPSG or Oracle code sets through the NameMapper can be painfully slow. Thus, this change will enable a very quick and easy way to build an association between CS-MAP key names and EPSG and Oracle code values.
CS-MAP has, for many years, ignored the axis specification of official Coordinate Reference System (CRS) definitions as adhereing to the definitions precisely often produced undesireable results (i.e. maps that would be rotated and mirrored in host graphic display systems) and ensuing service calls. It is now becomming necessary when dealing with certain exchange formats to use the officially blessed axes orientations. Placing the officially blessed axes orientation in the coordinate system definition enables a reliable and maintainable means of accessing both the CS-MAP quad code and the officially blessed quad code, comparing them, and acting accordingly when exporting/importing to/from certain data storage mechanisms.
Proposed Solution
We will rename and use existing elments in the referenced dictionary structures which have never been used. Thus, the format of all dictionaries remains the same. The dictionary compiler will be adjusted to recognize these new values in the ASCII, version controllable, version of the dictionaries placing the proper values in the assigned slots. The appropriate data will be added to the existing .asc files via an automated process based on the current contents of the NameMapper and the EPSG Parameter Dataset, version 7.05. No additional functions are planned.
Implications
Any code which references the currently unused elements in the three dictionary structures will not compile after this change. This should not be a problem as CS-MAP has never used them, never provided any interface to them, never documented them, and CS-MAP has always forced these values to the default value of zero.
Test Plan
TestN of the ConsoleTestCpp application, which currently compares the elements of definitions which the NameMapper says are the same, will be modified to verify that the EPSG code, Oracle SRID, EPSG Quadrant codes are consistent with the NameMapper and the current version of the EPSG Parameter Dataaset.
Funding/Resources
Development resources and funding to be provided by Autodesk.
