CS-Map RFC 1 - Creation of a GDC file to handle French grid files

Implemented the Geodetic Data Catalog feature for the French datum conversions 
between RGF93 and NTF.  This enables French localities to use locally generated 
datum shift files in the NTv2 format in addition to the standard nationally 
generated "gr3df97a.txt" data file.  The grid cell sizes in the respective data 
files causes CS-MAP to always use the local files in those cases where the 
coordinate to be converted is covered by the local file.

The new Geodetic Data Catalog file is named "Rgf93ToNtf.gdc" and is required to 
reside in the same directory as the coordinate system dictionary files.  In the 
distribution, the "gr3df97a.txt" file is moved to the France sub-directory, and 
local grid files are expected to be maintained there as well.

TESTING PERFORMED:
Eleven test cases were obtained from a French locality as used to test the 
implementation.  Prior to the effort, a list of 60 randomly generated 
coordinates using only the national gr3df97a.txt file shift was captured and 
added to the internal test program to verify that there were no regressions.  
These test passed on the Windows 32 and Linux platforms.

Whenever a coordinate is converted, all datum shift sources listed in the 
Geodetic Data Catalog file are examined and those sources whose extents of 
coverage include the point to be converted are noted.  The specific source with 
the densest grid (i.e. smallest grid cell size) is chosen.  As the local files 
are much denser than the national file, the local grid file is always chosen 
when appropriate.

The Geodetic Data Catalog file is named Rgf93ToNtf.gdc as this is the direction 
of the shift data contained in the nation gr3df97a.txt file.  Note that the 
local grid files tend to be in the opposite direction; i.e. the grid shift data 
contained in these files contains the latitude and longitude shift from NTF to 
RGF93.  This added some complexity to the implementation of this feature.

Upon this submission, the implementation does not match the eleven test points 
provided to the degree that we would normally expect.  I suspect that the 
problem is that our implementation of the Lambert Tangential does not produce 
the exact same numbers as that of the French Circe 2000 program.  I've done the 
same test using the Lambert Conformal Conic, Single Standard Parallel projection 
(technically the same projection, but a different implementation) and obtained 
the exact same results as our implementation of the LMTAN.  Also, the creep test 
on our implementation of the LMTAN indicates a creep of less than 2 millimeters 
per 1,000 round trips.  So, this discrepancy remains unresolved.  The 
discrepancy as of this submission averages about 2 millimeters, but gets as high 
as 8 millimeters.  A discrepancy of less than 2 millimeters would be normally 
expected.

git-svn-id: http://svn.osgeo.org/metacrs/csmap/trunk/CsMapDev@1499 4e78687f-474d-0410-85f9-8d5e500ac6b2
CS-Map RFC 1 - Creation of a GDC file to handle French grid files

Oops!! Forgot to add this file to the repository.  This is the actual Geodetic Data Catalog file which provides CS-MAP information about the files which it should use to perform the indicated datum conversion.

git-svn-id: http://svn.osgeo.org/metacrs/csmap/trunk/CsMapDev@1500 4e78687f-474d-0410-85f9-8d5e500ac6b2
Oops!!! I forgot to include this new test module with the submission for RFC - 1

git-svn-id: http://svn.osgeo.org/metacrs/csmap/trunk/CsMapDev@1501 4e78687f-474d-0410-85f9-8d5e500ac6b2
Adds four states to the HARN feature.  This requires addition of eight (8) files to the Usa/Harn folder, and four entries added to the Nad83ToHarn.gdc Geodetic Data Catalog file.  It turns out that the NGS has changed to lication at which these files are published on the Internet, and the existence of the data files for these four states has eluded us for several years now.  There are no code changes required; end users can make these same changes on their local systems.  End users also note, that the individual states can be added independently of the others.

MetaCRS Trac ticket: #27
Cross reference: Autodesk Defect ID: 1180341.
Submitter: Norm Olsen

git-svn-id: http://svn.osgeo.org/metacrs/csmap/trunk/CsMapDev@1510 4e78687f-474d-0410-85f9-8d5e500ac6b2
Committing files which were omitted from the submission which provided the correction for Trac ticket #4.  These files should have been a part of that submission, but were inadvertantly omitted.

git-svn-id: http://svn.osgeo.org/metacrs/csmap/trunk/CsMapDev@1516 4e78687f-474d-0410-85f9-8d5e500ac6b2
Trac #28 -- Added code to the CS_wktToCsEx function in the CS_wellKnownText.cpp module so that in the case of a WKT string that includes a TOWSG84 element (i.e. a complete Datum definition) and the Name Mapper fails to produce a dictionary datum name; we see if the WKT name is that of a datum dictionary name.  If so we use that name and establish a relationship between the WKT and the named datum dictionary definition.

git-svn-id: http://svn.osgeo.org/metacrs/csmap/trunk/CsMapDev@1524 4e78687f-474d-0410-85f9-8d5e500ac6b2
Fix for track ticket:
http://trac.osgeo.org/csmap/ticket/29

The Optimization flag is now set to "Maximize Speed (/O2)" in the Release 32 bit and the Release 64 bit targets in the Windows Visual Studio project file Library.vcproj


git-svn-id: http://svn.osgeo.org/metacrs/csmap/trunk/CsMapDev@1525 4e78687f-474d-0410-85f9-8d5e500ac6b2
Fixes Trac ticket #31.  Added "US48" as CS-MAP and Autodesk names and associated them with the previously existing Oracle 9 and ESRI names for this coordsinate systems.

git-svn-id: http://svn.osgeo.org/metacrs/csmap/trunk/CsMapDev@1549 4e78687f-474d-0410-85f9-8d5e500ac6b2
This file should have been submitted with the NameMapper.csv file that corrected Trac ticket #31, but it wasn't; I apologize.  Currently, the .csv files maintained in this directory are used to generate the NameMapper.csv file.

git-svn-id: http://svn.osgeo.org/metacrs/csmap/trunk/CsMapDev@1550 4e78687f-474d-0410-85f9-8d5e500ac6b2
git-svn-id: http://svn.osgeo.org/metacrs/csmap/trunk/CsMapDev@1551 4e78687f-474d-0410-85f9-8d5e500ac6b2
Adding a repository for CS-MAP dpcumentation.

This document exhibits all of the tell-tale signs of a document maintained by different people, using different tools, over a period of 20 years.  refinements continue; but this preliminary version is provided so that there is something.


git-svn-id: http://svn.osgeo.org/metacrs/csmap/trunk/CsMapDev@1552 4e78687f-474d-0410-85f9-8d5e500ac6b2
This submission addresses Trac tickets 15, 21, 22, 24, 25, & 26.

This corrects several of the inconveniences of building CS-MAP on Linux 64 bit systems.  Also note, that the perennial prolem of _wcsicmp has been resolved by writing our own equivalent: CS_wcsicmp in CS_ansi.c

Also note that the compilation failure on 64 bit gcc was due to the fact that a "long" in 64 bit gcc (and also Sun, by the way) is a 64 bit object.  CS-MAP uses the "long32_t" and "ulong32_t" wherever it is expecting a 32 bit integer value.  This useage should/must be adhered to in order to avoid similar problems in the future.

git-svn-id: http://svn.osgeo.org/metacrs/csmap/trunk/CsMapDev@1555 4e78687f-474d-0410-85f9-8d5e500ac6b2
This submission corrects Trac tickets 33 and 31; the corrections to these two defects share a common code module cs_wellknowntext.cpp

With regard to ticket 31:  The projection mathematics of conic projections which accept two standard parallels do not care about the order of the parallels.  CS-MAP has always put the northernmost parallel in prj_prm1 and the southernmost parallel in the prj_prm2.  This works fine until you want to compare definitions, for example, derived from WKT where the order of the parallels might be switched.  The change here is to: a> compare the standard parallels in a order independent manner, and b> when reading WKT, always insure that the northernmost parallel ends up in prj_prm1.

With regard to ticket number 33:  WHile ESRI WKT always has the prime meridian value in units of degrees, Oracle (both 10 and 9) and GeoTools output the prime meridian in the units of the host GEOGCS coordinate system.  Thus, CS-MAP has been readingt these things wrong for man years.  Not a big consequence, as the following must be in effect for this defect to be observable:

1> Prime meridian must be something other than Greenwich
2> GEOGCS system unit must other than degrees (e. g. grads)
3> The flavor of the WKT being processed must be Oracle9, Oracle, or GeoTools.

I have no information about what other flavors do in this case. so those have been left alone until such information is available.

git-svn-id: http://svn.osgeo.org/metacrs/csmap/trunk/CsMapDev@1556 4e78687f-474d-0410-85f9-8d5e500ac6b2
This submission corrects Trac tickets 31 & 34 as the correct share the same files:  ProjectiveKeyNameMap.csv and NameMapper .csv.

Ticket 31:  The CS-MAP coordinate system name "US48" was missing from the name mapping file, thus causing failures dealing with WKT import of this system.

Ticket 34: Six EPSG codes which were added by EPSG change 2007.34 were added to the NameMapper.  The EPSG mapping is getting rather outdated, so there will be more of these to come.

The six codes added are:

3734 -> OH83-NF
3735 -> OH83-SF
3736 -> WY83-EF
3737 -> WY83-ECF
3738 -> WY83-WCF
3739 -> WY83-WF


git-svn-id: http://svn.osgeo.org/metacrs/csmap/trunk/CsMapDev@1557 4e78687f-474d-0410-85f9-8d5e500ac6b2
Changes to implement the solution to Trac ticket 35.

Essentially, this submission completes the planned implementation of an TcsEpsgDataSetV6 object.  Provided with a set of .csv files which mirror the EPSG database as it exists in Access form (i.e. one .csv file for each of the 22 tables in the EPSG Access database), the TcsEpsgDataSetV6 object provides an easy means to extract all kinds of information from the EPSG dataset.  Of particular interest:  GetCsMapEllipsoid, GetCsMapDatum, and GetCsMapCoordsys.  Implementation of all sorts of other goodies will be mmuch easier using this object as a base.

Miscellaneous changes included:

1> The TcsCsvFileBase sorting function is now capabale of distinguishing between text and numeric fields automatically, thus enabling a sort by EPSG codes which produces the desired results.
2> Library.vcproj was modified to include a new source code module: csEpdgSupport.cpp and adjusted the environmental references such that the project could be included in other solutions without messing with the project's properties.
3> CS-MAP's projection table now includes the EPSG code for the projection.  This is accuirate in most cases.  In other cases, where the mapping of an EPSG Method to a CS-MAP projection is not a strict one to one relationship, the mapping is less accurate.  A zero value is used to indicate no mapping.
4> CS-MAP's projection paramater table now includes the EPSG code number of the equivalent parameter.  Again, this is accurate and useful for a small number of heavily used parameters.  In cases where is the relataionship between EPSG and CS-MAP parameters is not clear cut, the code is an approximation or zero.
5> We've added some exceptions to the lcl.lnt file.  Just about everything in CS-MAP now passes the PC-Lint test.  Eventually, we'll have them all in line.



git-svn-id: http://svn.osgeo.org/metacrs/csmap/trunk/CsMapDev@1572 4e78687f-474d-0410-85f9-8d5e500ac6b2
This is Trac ticket 35 again.  COmpleteing the implementation of the EPSG Dataset access object.  I keep forgetting to "Add" the new functions before doing a commit.  I'll learn one of these days.

git-svn-id: http://svn.osgeo.org/metacrs/csmap/trunk/CsMapDev@1573 4e78687f-474d-0410-85f9-8d5e500ac6b2
This submission addresses Trac ticket 36.

The original CS-MAP console test program was written in C, as was the entire CS-MAP library at that time.  As more and more C++ has crept into the CS-MAP library, having the console test program as a C program had become quite inconvenient.  This submission submits a version of the CS-MAP Console Test program which has been modified so that it all complies as C++, making it rather easy to call, exercise, and test features of the library which are written in C++ as well as those written in C.

The primary driving factor behind this submission was the desire to access our new TcsEpsgDataSetV6 object in our console test program.  There are two new tests:

CStestM.cpp  ->  Implements the Name Mapper audit test, where the names and ID's maintained in the Name Mapper database are compared to external data sources for accuracy and concurrency.  Currently, only the EPSG external database is used in the testing process.

CStestN.cpp  -> Implements the CS-MAP Dictionary and EPSG Dataset comparison test.  For each definition in a EPSG Dataset for which the Name Mapper database contains a mapping, the EPSG version of the definition is compared with the CS-MAP version.  This verifies that the Name Mapper maps to the correct definition, and also flushes out any discrepancies in the definitions which might exist.

Finally, To implement TestN in a rational manner, a more discerning set of compariaon functions was necessary.  The following three functions were added and are used solely in TestN of the C++ version of the console test program.

CS_elDefCmpEx ()  -> A new function which compares ellipsoid definitions returning a double value which indicates the degree to which the compared ellipsoids are the same.

CS_dtDefCmpEx ()  -> A new function which compares datum definitions returning a double value which indicates the degree to which the compared datum definitions are the same.

CS_csDefCmpEx ()  -> A new function which compares coordinate system definitions returning a double value which indicates the degree to which the compared coordinate systems are the same.



git-svn-id: http://svn.osgeo.org/metacrs/csmap/trunk/CsMapDev@1574 4e78687f-474d-0410-85f9-8d5e500ac6b2
This submission is in response to Trac Ticket #37.

This submission goes a long way to getting the NameMapper facility up to date with EPSG 6.18.  The modifications submitted here are those which can be made without any corresponding dictionary changes.  The bulk of the changes can be catgorized into two types:
1> Definitions for which there has been a CS-MAP definition for some time, but a EPSG code has only  recently been assigned,
2> Definitions deprecatedby EPSG and therefore have a new and different code number even though the definition did not change numerically.

There are some code chnges here as well.  These changes deal with the .csv files in the Data folder which are used to produce the NameMapper.csv file by compilation.  The first column of these files used to carry an InternalID number; the first column now carries a sequence number.  The NameMapper file supports fields for comments and remarks, but the NameMapper object had no provisions for setting or getting these fields; this has been changed as well.

Fianaly, to test the validity of the changes made, the new ConsoleTestCpp program was heavily used.  I added the ConsoleTestCpp project to the OpenSource solution file.


git-svn-id: http://svn.osgeo.org/metacrs/csmap/trunk/CsMapDev@1576 4e78687f-474d-0410-85f9-8d5e500ac6b2
Quick change to fix a build on Linux problem.  Appears the use of swprintf is rather problematical in multi-platform environments.  Essentially, gcc wants the second argument to be the size of the buffer, while VC++ 9.0 is overloaded and will take it either way.

git-svn-id: http://svn.osgeo.org/metacrs/csmap/trunk/CsMapDev@1581 4e78687f-474d-0410-85f9-8d5e500ac6b2
This submission corrects Trac Ticket #39.

A memory leak was discovered in the situation where a WKT definition is imported and the NameMapper fails to produce a datum match between the definition and the CS-MAP dictionaries.  The leak consist of a single copy (per processed WKT definitioin which produces this relatively rare situation) of the cs-Dtdef_ structure, about 200 bytes.

Ref LUC009NTO01.txt


git-svn-id: http://svn.osgeo.org/metacrs/csmap/trunk/CsMapDev@1582 4e78687f-474d-0410-85f9-8d5e500ac6b2