|
MIGRATION GUIDE
SEDRIS SDK Release 3.1.x to Release 4.0.x |
|---|
This migration document describes the required changes to migrate applications developed using SEDRIS SDK Release 3.1.x to SEDRIS SDK Release 4.0.x. This document covers all aspects of the SDK. New SEDRIS SDK users do not need to read this document.
This document provides the key migration concepts and has links to the detail changes such as function and name changes.
For general information about this release and items that require specific attention, see the Release Notes.
For help with the migration process or other questions and comments please send email to help@sedris.org. If you are an associate, please send email to se-coders@sedris.org.
Return to: Top
This release includes a name replacement Perl script (name_change.pl) that can help users to replace old names in their source code (i.e. function names, data type names, etc.) with the new ones. This script covers most of the cases where there is a one-to-one mapping. However, there are cases where manual editing of the source code will be required. In addition, the script can be customized to map user-defined types. Please read the Name Change script Readme file for more information.
Return to: Top
This section describes the changes to the source tree structure and file names. This information is only relevant if you are using a source code distribution.
- The read0 and write0 directories were merged into a single directory called taccess0 and similarly the read1 and write1 directories were merged into a single directory called taccess1.
- The SRM directory structure has been changed significantly to accommodate the addition of the SRM C++ API.
Return to: Top
This section summarizes the major changes to the DRM technology component. For detailed changes on DRM related SCRs see Migration Guide - DRM SCRs. For detailed information on DRM type and function changes, see Migration Guide - DRM and DRM API. For further information on class field mappings, other individual class changes, and constraint changes, see Migration Guide - Classes.
The following are general DRM API changes:
- Macros wrapping functions have changed names if the functions they wrap have changed names. For example, SE_GetTokenName() which wraps SE_GeneralTokenName() was renamed SE_GetDRMClassString().
The following are the major DRM changes that require a user to modify their processing of transmittals:
- The associate relationship between the <Feature Representation>s, <Geometry Hierarchy>s, and <Feature Representation>s to <Geometry Hierarchy>s are now one way, and takes a link object (a <Base Association Data> instance) specifying the semantic meaning of the relationship. Previously, objects of these classes with an associate relationship were defined to be alternate representations of the same environmental object. In Release 4.0.x alternate representation is only one of the relationships that can exist, see CORE-assoc.
- The inheritance of <Classification Data> objects are explicitly stated through the fields of <Union Of Features> and <Union Of Geometry>, see CORE-197.
- The <Hierarchical Table> subclasses have been eliminated from the DRM and thus any exception code for processing objects under these classes can be removed, see SAIC-170 for the exact changes.
- New support was provided for 3D topology for geometry and feature representations, see NGIT-001 and NGIT-002.
- The DRM changes due to SRM changes are described in Release 4.0.x SRM Migration Notes. The overview is as follows:
- There are now three abstract DRM Location classes (2D, Surface, & 3D) instead of two. There is one concrete class defined per SRF Template, refer to the SRM documentation.
- The classes AUPS 3D/UPS 2D are stored in PS 3D/PS Surface. The class GCS 3D is stored using the LTE 3D class. The classes AUTM 3D/UTM 2D are stored using the TM Augmented 3D/TM Surface classes. This change corresponds to the concept of SRF Sets in the SRM documentation.
- The SRM related information is stored in the SE_SRF_Info type which separates the SRF template information and the vertical offset surface information as well as including SRM units.
- The DRM changes due to EDCS changes are described in Release 4.0 EDCS Migration Notes.
Return to: Top
This section summarizes the major changes to the EDCS technology component. For detailed changes on EDCS related SCRs see Migration Guide - EDCS SCRs. For detailed information on EDCS changes see Migration Guide - EDCS Concepts and Migration Guide EDCS API.
The following are the general EDCS changes:
- This version of EDCS is the implementation of the ISO EDCS specificaion FDIS version. Therefore the concepts defined herein will be consistent with that specification.
- There is a new set of primitive types that are now specifically defined for the EDCS API and start with the "EDCS_" prefix.
- Symbolic constants have their prefix changed to "ECC_" for Classifications, "EAC_" for Attributes, and "EEC_" for Enumerants.
- New dictionaries for Attribute Value Characteristic, Unit, and Scale:
- The EDCS_UNITS_ENUM type was replaced by two mechanisms, EDCS_Unit_Code and EDCS_Scale_Code.
- Some enumerations had metadata enumerants. Those enumerants have been mapped to entries in the Attribute Value Characteristic dictionary. The SE_Property_Data_Value structure has changed to accommodate meta-values.
- An attribute of type real is now handled as a EDCS_Real_Value structure containg the Long Float value a EUC, and a ESC. As a result the function EDCS_ConvertQuantatyValue() now takes in only two parameters of type EDCS_Real_Value insted of the previous six parameters.
Return to: Top
This section summarizes the major changes to the SRM technology component. For detailed information on SRM changes see Migration Guide - SRM.
- The SRM API has additional functionality with minor changes to the API. The only major change is that the user is not required to work with SRF_Parameter_Pair. Instead the user will create specific SRFs and pass in the handles to the SRFs for conversion using SRF specific functions.
- The SRM API has functions defined for both moving from the SRM constructs and the DRM constructs used for storage as well as utility functions for using the SRM within a DRM context. These functions are described in the under the SRM C API reference manual File List of srm_level_0.h, srm_util.h, and srm_special_util.h listings,
Return to: Top
This section summarizes the major changes to the Transmittal Access API technology component. For detailed changes on Transmittal Access API related SCRs see Migration Guide - Transmittal Access API SCRs. For detailed information on Transmittal Access API changes see Migration Guide - Transmittal Access API.
- API calls return SE_Return_Code instead of SE_Status_Code with the result being either a success or failure. More descriptive results will be provided through the call SE_GetLastFunctionStatus. See CORE-184 for specific details.
- The API constructs SE_Object_ID have been eliminated and replaced with simple strings. See CORE-185 for specific details.
- The storage and retrieval of Data Table Data is now performed with 2 new functions. Software using the previous functions will need to be modified to use the new function per CORE-186.
- SE_PutFields now verifies that the field values are syntactically valid, if they are not, then the object will contain default fields.
- The functions SE_GetComponent(), SE_GetAggregate(), & SE_GetAssociate have been simplified to retrieve one object.As a result SE_GetComponent has had the max_search_distance parameter removed
- The API accepts implementation_identifiers as an enumeration instead of an open ended string. Therefore instead of passing in "stf" or "STF" to functions such as SE_CreateStore, a user will pass in SE_ENC_STF of type SE_ENCODING
|