Changes between Version 3 and Version 4 of CsMapRfc5

Timestamp:

Jun 21, 2011, 3:14:17 PM (13 years ago)

Author:

Norm Olsen

Comment:

--

CsMapRfc5

@@ -48 +48 @@
 Most all of the conversions and many of the transformations within CS-MAP are inherently reentrant and have been for some time.   In Phase One of this proposal, we simply provide information to the developer as to the reentrant behavior of any given conversion and/or transformation, or combination thereof.  Given this information, a developer can determine if using multiple threads is safe and/or if an exclusive lock needs to be applied to a specific portion of the entire conversion process.
 
+Implementation of Phase One will be accomplished by adding a new property to the projection flags element of the projection table.  Using this feature, each projection will be classified as being reentrant or non reentrant.  (Currently, only the OSGB variations of the Transverse Mercator which use the ordnance survey grid tables are known to be non-reentrant).  A similar feature was designed in the the Geodetic Trnasformation table, but is as yet unused.  Thuis feature will be implemented and each geodetic transformation method classified in the table as being either reentrant or not reentrant.
+
+Implementing the API's for this feature is then a matter of extracting the conversion/transformation method and extracting the reentrancy bit from the properties flag word of the appropriate table.
+
 === Phase Two ===
 Those CS-MAP conversions and transformations which are not reentrant are usually that way due to the heritage of CS-MAP (the days of the 640KB PC and no more than 8 files open at one time) and the level of resource consumption which would be necessary to achieve reentrant status.  In Phase Two of this proposal, all non-reentrant conversions and transformations for which reentrancy can be achieved without unreasonable additional resource consumption will be recoded to achieve reentrancy.
@@ -53 +57 @@
  * insure that exceptions are not encountered, and to
  * prevent a reentrancy requirement from precluding valuable future additions to the algorithmic repertoire of the library.
+
+Currently, the geocentric and multiple regression transformation methods are considered reentrant.  All of the grid file interpolation methods are considered to be non-reentrant.  Grid file interpolation techniques tend to be non-reentrant as the code typically buffers data from the grid file in the transformation object for performance reasons.  Unless the file is buffered in its entirity, the object becomes non-reentrant.  An object that does no buffering at all would be reentrant, but would probably suffer a performance hit.  Thus, completing Phase Two will require some non-trivial engineering efforts.